AWS MCP Servers — helping you get the most out of AWS, wherever you use MCP. - awslabs/mcp
Read the original article
Comments
By danielvaughn 2025-08-1814:317 reply The approach I've taken to "vibe coding" is to just write pseudo-code and then ask the LLM to translate. It's a very nice experience because I remain the driver, instead of sitting back and acting like the director of a movie. And I also don't have to worry about trivial language details.
Here's a prompt I'd make for fizz buzz, for instance. Notice the mixing of english, python, and rust. I just write what makes sense to me, and I have a very high degree of confidence that the LLM will produce what I want.
fn fizz_buzz(count): loop count and match i: % 3 => "fizz" % 5 => "buzz" both => "fizz buzz"That's a really powerful approach because LLMs are very very strong at what is basically "style transfer". Much better than they are at writing code from scratch. One of my most recent big AI wins was going the other way; I had to read some Mulesoft code in its native storage format, which is some fairly nasty XML encoding scheme, mixed with code, mixed with other weird things, but asking the AI to just "turn this into psuedocode" was quite successful. Also very good at language-to-language transfer. Not perfect but much better than doing it by hand. It's still important to validate the transfer, it does get a thing or two wrong per every few dozen lines, but it's still way faster than doing it from scratch and good enough to work with if you've got testing.
By hardwaregeek 2025-08-1814:502 reply My mental model for LLMs is that they’re a fuzzy compiler of sorts. Any kind of specification whether that’s BNF or a carefully written prompt will get “translated”. But if you don’t have anything to translate it won’t output anything good.
By gyomu 2025-08-1821:01 > if you don’t have anything to translate it won’t output anything good.
One of the greatest quotes in the history of computer science:
“On two occasions I have been asked, – "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question"
By danielvaughn 2025-08-1815:48 Yep, exactly. "Garbage in, garbage out" still applies.
By hangonhn 2025-08-1815:50 I agree with that assessment but that makes me wonder if a T5 style LLM would work better than a decoder only style LLM like GPT or Claude. Has anyone tried that?
By globular-toast 2025-08-1815:143 reply Is this seriously quicker than just writing in a language that you know? I mean, you're not benefitting from syntax highlighting, autocompletion, indentation, snippets etc. This looks like more work than I do at a higher cost and insane latency.
By CJefferson 2025-08-1817:501 reply I find it particularly useful when I would need to look up lots of library functions I don't remember. For example, in python I recently did something (just looked it up:
I don't python enough to remember reading all files in a directory, or splitting strings. I didn't even bother proof reading the English (as you can see)for ever my file in directory 'd' ending '.capture': Read file Split every line into A=B:C Make a dictionary send A to [B,C] Return a list of pairs [filename, dict from filename]By stahorn 2025-08-1819:08 Same when you a few times per year need to write some short bash script. It's really nice to not have to remember how it really works again!
By danielvaughn 2025-08-1815:242 reply Those are just features waiting to be developed. I'm currently experimenting with building LLM-powered editor services (all the stuff you mentioned). It's not there yet, but as local models become faster and more powerful, it'll unlock.
This particular example isn't very useful, but anecdotally it feels very nice to not need perfect syntax. How many programmer hours have been wasted because of trivial coding errors?
By globular-toast 2025-08-1815:481 reply > How many programmer hours have been wasted because of trivial coding errors?
Historically probably quite a lot, but with a decent editor and tools like gofmt that became popular in the past 10 years I'd say syntax is just not a problem any more. I can definitely recall the frustration of a missing closing bracket in HTML in the 90s, but nowadays people can turn out perfectly syntactically correct code on day 1 of a new language.
By danielvaughn 2025-08-1816:061 reply That’s fair. Not to shift the goal post but my intuition has shifted recently as to what I’d consider a “trivial” problem. API details, off-by-one errors, and other issues like that are what I’d lump into that category.
Easy way to say it is that source code requires perfection, whereas pseudo-code takes the pressure off of that last 10%, and IMO that could have significant benefits for cognitive load if not latency.
Still all hypothetical, and something I’m actively experimenting with. Not a hill I’m gonna die on, but it’s super fun to play and imagine what might be possible.
By motorest 2025-08-1817:52 > Is this seriously quicker than just writing in a language that you know?
Yes. Well, it depends.
Most of the prompts specifying requirements and constraints can be reused, so you don't need to reinvent the wheel each time you prompt a LLM to do something. The same goes for test suites: you do not need to recreate a whole test suite whenever you touch a feature. You can even put together prompt files for specific types of task, such as extending test coverage (as in, don't touch project code and only append unit tests to the existing set) or refactoring work (as in, don't touch tests and only change project code)
Also, you do not need to go for miracle single-shot sessions, or purist all-or-nothing prompts. A single prompt can fill in most of the code you require to implement a feature,and nothing prevents you from tweaking the output.
It is seriously quicker because people like you and me use LLMs to speed up how the boring stuff is implemented. Guides like this are important to share some lessons on how to get LLMs to work and minimize drudge work.
By unshavedyak 2025-08-1814:431 reply I do something similar, merely writing out the function signatures i want in code. The more concrete of the idea i have in my head the more i outline, outline tests, etc.
However this is far less vibe coding and more actual work with an LLM imo.
Overall i'm not finding much value in vibe coding. The LLM will "create value" that quickly starts to become an albatross of edge cases and unreviewed code. The bugs will work their way in and prevent the LLM from making progress, and then i have to dig in to find the sanity - which is especially difficult when the LLM dug that far.
By danielvaughn 2025-08-1815:27 Yeah I'm nowhere near ready to loosen the leash. Show me a long-running agent that can get within 90% of its goal, then I'll be convinced. But right now we barely even have the tools to properly evaluate such agents.
By kristoff200512 2025-08-197:16 I initially used natural language as prompts, but the code output wasn’t ideal. When I listed the steps it should follow, I found that it executed them very well.
By animal531 2025-08-1914:25 I've had great success with this with pseudo-code from research papers. I don't always understand the syntax but the LLM has no such problems.
By j45 2025-08-1912:26 Pseudo code is a great idea, similar to explaining how something should run
I do something like that when I get down to the function level and there is an algorithm that is either struggling for the role or poorly optimized, but the models that excel in codebase architecture have their hands held behind their back with that level of micromanaging.
the results are good because as another replier mentioned, LLMs are good at style transfer when given a rigid ruleset -- but this technique sometimes just means extra work at the operator level to needlessly define something the model is already very aware of.
"write a fizzbuzz fn" will create a function with the same output. "write a fizzbuzz function using modulo" will get you closer to verbatim -- but my point here is that in the grand scheme of "will this get me closer to alleviating typing-caused-RSI-pain" the pseudocode usually only needs to get whipped out when the LLM does something braindead at the function level.
By nine_k 2025-08-1818:11 But "write a fizzbuzz fn" has one important assumption / limitation: the LLM should have seen a ton of fizbuzz implementations already to be able to respond.
Hence, LLMs can be helpful to produce boilerplate / glue code, the kind that has already been written in many variations, but cannot be directly reused. Anything novel you should rather outline at a more detailed level.
> Always: > > Thoroughly review and understand the generated code
Rules it out for me; I haven’t felt I thoroughly understood any code after working with C++ and reading the entries in code obfuscation contests.
It’s a bit of a catch-22 to say “anyone can code with AI” and then make such statements.
By thewebguyd 2025-08-1815:584 reply > It’s a bit of a catch-22 to say “anyone can code with AI” and then make such statements.
Also makes it very much not "vibe" coding. The term keeps expanding into "any coding activity with AI assistance" but the whole idea of "vibe" coding is that you don't actually understand the generated code, and likely don't know how to program at all, you're just prompting AI to do everything.
Once you step into reviewing & understanding, you're no longer vibe coding you're just...coding.
By heyparkerj 2025-08-1816:15 I've expressed this to others as much as is reasonable - but the phrase "vibe coding" shouldn't be used in any serious discourse about agentic tools. We can't control the lens under which a given person first heard the term, but that moment (combined with the mountains of memes they've consumed since) is going to color a lot of folk's personal definition of vibe coding. It's not realistic to expect everyone to have a shared definition of it, despite the inventor of the phrase immediately giving it definition.
By michelsedgh 2025-08-1820:11 You are, I think reviewing and understanding the code and the app are very important, but the moment you go in and code yourself you're not vibe coding anymore. I think you break vibe coding when you touch the code yourself and have to manually make edits not when understanding and making sure the llm did what you asked it.
By seunosewa 2025-08-1818:45 The first self-announced vibe coder was a founder of OpenAI. So he had the knowledge.
He started to trust the code written by the models to a point where he didn't always read the code. This happens when you you have learned the exact limits of your models.
It's like a senior coder who knows the projects the interns can handle without close supervision, and those they can't.
By _puk 2025-08-1820:36 I just call it vybrid coding :)
By gs17 2025-08-1816:51 > I haven’t felt I thoroughly understood any code after working with C++ and reading the entries in code obfuscation contests.
Seems to me the result should be that if you aren't sure, your feedback when reviewing the code is that it needs to be more readable. Send it back to the LLM and demand they make it easier to understand.
> Always: > > Thoroughly review and understand the generated code
I think this is good advice actually. We do allow LLM agents where I work, but you still need to understand every line of code that you write or generate. That’s probably why we still do physical interviews as well.
It's great advice for anything AI-generated in a professional production environment. I think the question is whether it's vibe coding with that requirement in place. Or, rather, if the requirement is appropriate for how vibe coding is often used and promoted today (by non-coders).
Basically all of the suggestions on that page were good practice, and not just for code. Documenting your changes, reviewing the output of an AI (or junior person), writing meaningful commits ... all of these apply equally to code, contracts, whatever. I read this post as "If you want vibe coding to be coding you still have to do a lot of hard work and not treat it as a magic app engine." Which is true but absolutely not what a lot of vibe code-embracing middle managers want to hear.
By oeitho 2025-08-1818:50 I agree. Personally, I barely use any LLM tools professionally as a developer, and I don't use it at all in my free time. I do however have some coworkers that use it more heavily. Having a culture of proper code reviews and requirements that you need to know what the code in your PR does ensures that we have create proper solutions.
I don't think I could enjoy working at a place where people didn't know the content of the commits they made. I remember the early talks of vibe coding being that you're not even supposed to look at the code, and have been very happy that I haven't met anyone professionally that codes like that.
By colesantiago 2025-08-1813:391 reply > "Thoroughly review and understand the generated code"
That isn't vibe coding though.
Vibe coding means you don't look at the code, you look at the front / back end and accept what you see if it meets your expectations visually, and the code doesn't matter in this case, you "see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works." [1]
If the changes are good enough, i.e. the front/backend works well, then it's good and keep prompting.
You rely on and give in into the ~vibes~. [1]
By kevindamm 2025-08-1814:00 Maybe the zeroth tip is "never go full vibe coder."
It can be tempting, but there's so much impact that even small changes to the code can have, and often in subtle ways, that it should at least be scanned and read carefully in certain critical parts. Especially as you near the point where hosting it on AWS is practical.
Even in Karpathy's original quote that you referenced he says "It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding." Maybe it should have been called vibe prompting.
