Counterexample: Ive been able to complete more side projects in the last month leveraging llms than i have ever in my life. One of which I believe to have potential as a viable product, and another which involved complicated rust `no_std` and linker setup for compiling rust code onto bare metal RISCV from scratch.

I think the key to being successful here is to realize that you're still at the wheel as an engineer. The llm is there to rapidly synthesize the universe of information.

You still need to 1) have solid fundamentals in order to have an intuition against that synthesis, and 2) be experienced enough to translate that synthesis into actionable outcomes.

If youre lacking in either, youre at the same whims of copypasta that have always existed.

In my experience LLMs will help you with things that have been solved thousands of times before and are just a matter of finding some easily researched solution.

The very moment when you try to go off the beaten path and do something unconventional or stuff that most people won't have written a lot about, it gets more tricky. Just consider how many people will know how to configure some middleware in a Node.js project... vs most things related to hardware or low level work. Or even working with complex legacy codebases that have bits of code with obscure ways of interacting and more levels of abstraction that can be reasonably put in context.

Then again, if an LLM gets confused, then a person might as well. So, personally I try to write code that'd be understandable by juniors and LLMs alike.

> AI isn’t a co-pilot; it’s a junior dev faking competence. Trust it at your own risk.

This is a good take that tracks with my (heavy) usage of LLMs for coding. Leveraging productive-but-often-misguided junior devs is a skill every dev should actively cultivate!

I used Claude to help me build a side project in 4 hours that I would never have built otherwise. Essentially, it's a morphing wavetable oscillator in React (https://waves.tashian.com).

Six months ago, I tried building this app with ChatGPT and got nowhere fast.

Building it with Claude required a gluing together a few things that I didn't know much about: JavaScript audio processing, drawing on a JavaScript canvas, an algorithm for bilinear interpolation.

I don't write JavaScript often. But I know how to program and I understand what I'm looking at. The project came together easily and the creative momentum of it felt great to me. The most amazing moment was when I reported a bug—I told Claude that the audio was stuttering whenever I moved the controls—and it figured out that we needed to use an AudioWorklet thread instead of trying to play the audio directly from the React component. I had never even heard of AudioWorklet. Claude refactored my code to use the AudioWorklet, and the stutter disappeared.

I wouldn't have built this without Claude, because I didn't need it to exist that badly. Claude reduced the creative inertia just enough for me to get it done.

I have used LLMs as a tool and I start to "give up" working with it after a few tries. It excels at simple tasks, boilerplate, or scripts but larger programs you really have to know what exactly you want to do.

I do see the LLMs ingesting more and more documentation and content and they are improving at giving me right answers. Almost two years ago I don't believe they had every python package indexed and now they appear to have at least the documentation or source code of it.

I've had a similar experience, shipping new features at incredible speed, then waste a ton of time going down the wrong track trying to debug something because the LLM gave me a confidently wrong solution.

One strategy I've been experimenting with is maintaining a 'spec' document, outlining all features and relevant technical notes about a project. I include the spec with all relevant source files in my prompt before asking the LLM to implement a new change or feature. This way it doesn't have to do as much guessing as to what my code is doing, and I can avoid relying on long-running conversations to maintain context. Instead, for each big change I include an up-to-date spec and all of the relevant source files. I update the spec to reflect the current state of the project as changes are made to give the LLM context about my project (this also doubles as documentation).

I use an NPM script to automate concatenating the spec + source files + prompt, which I then copy/paste to o1. So far this has been working somewhat reliably for the early stages of a project but has diminishing returns.

I ask this question without a hint of tone or sarcasm. You said: "*it’s a junior dev faking competence. Trust it at your own risk.*" My question is simply: "wouldn't you expect to personally be able to tell that a human junior dev was faking competence?" Why should it be different with the LLM?

I’ve been able to do more far complex things with ESP32s and RPis in an evening without knowing the first thing about python or c++.

I can also tell when it’s stuck in some kind of context swamp and won’t be any more help, because it will just keep making the same stupid mistakes over and over and generally forgetting past instructions.

At that point I take the last working code and paste it into a new chat.

Most LLMs default to being sycophantic yes-men, but if you create a custom prompt, it can help mitigate any issues.

I have a custom prompt that instructs gpt4o to get aggressive about attacking anything I say (and, importantly, anything it says).

Here's my result for the same question:

https://chatgpt.com/share/67984aa9-1608-8012-be93-a77728ab8e...

As opposed to not trusting an LLM, and ending up on day 4 of an afternoon project? :P

I've been doing that since way before LLMs were a thing.

Perhaps being a PM for several years has helped, I’ve had great success speeding up my programming workflows by prompting Claude with very specific, well defined tasks.

Like many others are saying, you need to be in the drivers seat and in control. The LLM is not going to fully complete your objectives for you, but it will speed you up when provided with enough context, especially on mundane boilerplate tasks.

I think the key to LLMs being useful is knowing how to prompt with enough context to get a useful output, and knowing what context is not important so the output doesn’t lead you in the wrong direction.

Funny enough, I posted an article I wrote here yesterday with the same sort of thesis. Different technologies (mine was Docker) but same idea of LLM leading me astray and causing a lot of frustration

Your plan was to use USB, but to me it looks like you're pretty much just using serial via USB. That's completely fine of course! One cheap way to tackle your problem is to use a version of printf with locking, which is likely available in many microcontroller SDKs (it's also slow). (Or you could add your own mutex.)

USB-CDC is cooler than that, you can make the Pico identify as more than just one device. E.g. https://github.com/Noltari/pico-uart-bridge identifies as two devices (so you get /dev/ttyACM0 and /dev/ttyACM1). So you could have logs on one and image transfers on another. I don't think you're limited to just two, but I haven't looked into it too far.

You can of course also use other USB protocols. For example you could have the Pico present itself as a mass-storage device or a USB camera, etc. You're just limited by the relatively slow speed of USB1.1. (Though the Pico doesn't exactly have a lot of memory so even USB1.1 will saturate all your RAM in less than 1 second)

FWIW, I fed in the same problematic prompt to all the current ChatGPT models and even the legacy/mini models enumerated a bunch of pitfalls and considerations. I wonder why/how it managed to tell the author everything was perfect? A weird one-off occurrence?

Really enjoyed reading your article. Haven’t laughed as much reading a tech article in quite some time. You should consider doing some YouTube videos as your communications style is very humble and entertaining.

Made me wanna join in your garage and help out with the project :)

Counterpoint: I'm on day 26 of an afternoon project I never would have attempted on my own, and I'm going to release it as a major feature.

Cursor & Claude got the boilerplate set up, which was half the mental barrier. Then they acted as thought partners as I tried out various implementations. In the end, I came up with the algorithm to make the thing performant, and now I'm hand-coding all the shader code—but they helped me think through what needed to be done.

My take is: LLMs are best at helping you code at the edge of your capabilities, where you still have enough knowledge to know when they're going wrong. But they'll help you push that edge forward.

Today, I needed to write a proxy[0] that wraps an object and log all method calls recursively.

I asked claude to write the initial version. It came up with a complicated class based solution. I spent more than 30 minutes getting a good abstract to come out. I was copy pasting typescript errors and applying fixes it suggested without thinking much.

In the end, I gave up and wrote what I wanted myself in 5 minutes.

0] https://github.com/cloudycotton/browser-operator/blob/main/s...

I spend a good portion of my time asking people to fix their LLM code now at work. It has made code reviews tiring. And it has increased pairing time significantly, making it a less fun activity.

Nemo, are you using a self-hosted install or .com?

If .com, email me (it's in my profile) and I can see if there is a reason your account is getting so heavily captcha'd.

> junior dev faking competence

A bit on a tangent, but has there been any discussion of how junior devs in the future are ever going to get past that stage and become senior dev calibre if companies can replace the junior devs with AIs? Or is the thinking we'll be fine until all the current senior devs die off and by then AI will be able to replace them too so we won't need anyone?

1. CS/Eng degree 2. ??? 3. Senior dev!

What I learned is you can’t outsource expertise to an LLM, after many similar experiences to OP. Don’t ask it for advice, ask it to teach you so you can make decisions like this on your own. Preferably ground questions with excerpts from human made documents. It seems to make less mistakes when explaining things, and those mistakes are more noticeable when they do happen.

One of the areas where I've struggled to get effective use out of the LLM's is with UI/UX. That isn't my primary area of expertise (backend) so it definitively could be operator error here, but I use tools like v0.dev and just can't quite get it to do what I need it to do. Anybody have any tools, workflows, suggestions for this?

> "From her perspective, I order doordash and turn into a degen who is unfit to father. From my perspective, I get to enjoy my favorite place and just tinker or play games or do whatever. These are the days I get to play mad scientist and feel most like myself."

Most demeaning and depressingly toxic thing I've read today...

That’s a fun writeup.

I’ve come to a similar conclusion - for now at least it’s best applied at a fairly granular level. Make me a red brick wall there rather than „hey architect make me a house“.

I do think OP tried a bit too much new stuff in one go though. USB plus zig is quite a bit more ambitious than the traditional hello world in a new lang

I have never found a use for LLMs for programming because I can find the (correct) answer much easier with a search. Perhaps the search engines just suck so hard these days people resort to LLMs. I use Kagi and GitHub to search and the results are much better.

LLM == WGCM = Wild Goose Chase Model

You are running the show and the LLM can act like many other roles to help you. Obscure or confusing topics, likely the LLM will be as bad at solving as any employee. Give it a plan. Follow up and make sure it’s on track.

I've found them tobe quite a time saver, within limits. The blog post seemed scattered and disorganized to me, and the author admits having no experience with using LLMs to this end, so perhaps the problem lies behind their eyes.

I'm developing an intuition to how and what to ask in order for the LLM's answer to be helpful. Once you start spinning your wheels, clear context, copy what you need, and start over.

OP could have written the firmware in zig, too!

https://github.com/ZigEmbeddedGroup/microzig

> As they say, I was trying to get a few birds stoned at once.

Imma gonna have to work this into a convo some day. Just to see the “wait, what??” expressions on people’s faces.

> My wife and I have a deal where 1 day a month, She takes the kiddo and I am absolved of all responsibilities. I get a full day to lock in and build projects.

I love it!

I used very similar hardware to accomplish a very similar project (Notifications on a round screen) and the LLM was great for everything except UX.

There's not much actual LLM-generated text in this post to go by, but it seems like each of the tokens generated by the LLM would be reasonable to have high probability. It sounds like the developer here thought that the sequence of tokens then carried meaning, where instead any possible meaning came from the reading. I wonder if this developer would be as irritated by the inaccuracies if they had cast sticks onto the ground to manage their stock portfolio and found the prophecy's "meaning" to be plausible but inaccurate.

A few mitigation ideas

  * Get AI to write tests
  * Use copy/paste. No IDE
  * Use python (not because it's better than zig)

I doubt one experience, positive, or negative counts for them all.

Learning how to build or create with a new kind of word processor is a skill unto itself.

I am frankly tired of seeing this kind of post on HN. I feel like the population of programmers is bifurcating into those who are committed to mastering these tools, learning to work around their limitations and working to leverage their strengths… and those who are committed to complaining about how they aren’t already perfect Culture Ship Minds.

We get it. They’re not superintelligent at everything yet. They couldn’t infer what you must’ve really meant in your heart from your initial unskillful prompt. They couldn’t foresee every possible bug and edge case from the first moment of conceptualizing the design, a flaw which I’m sure you don’t have.

The thing that pushes me over the line into ranting territory is that computer programmers, of all people, should know that computers do what you tell them to.

Context matters a lot, copy-pasting snippets to a webpage is _way_ less effective than Cursor/Windsurf.

for what it’s worth, my afternoon projects tend to take over four days even if no llm is involved

The OP misunderstands (perhaps deliberately or for humorous effect) what a co-pilot is. This is telling:

"I learned that I need to stay firmly in the driver’s seat when tackling new tech."

Er, that's pretty much what a pilot is supposed to do! You can't (as yet) just give an AI free reign over your codebase and expect to come back later that day to discover a fully finished implementation. Maybe unless your prompt was "Make a snake game in Python". A pilot would be supervising their co-pilot at all times.

Comparing AIs to junior devs is getting tiresome. AIs like Claude and newer versions of ChatGPT have incredible knowledge bases. Yes, they do slip up, especially with esoteric matters where there are few authoritative (or several conflicting) sources, but the breadth of knowledge in and of itself is very valuable. As an anecdote, neither Claude nor ChatGPT were able to accurately answer a question I had about file operation flags yesterday, but when I said to ChatGPT that its answer wasn't correct, it apologised and said the Raymond Chen article it had sourced wasn't super clear about the particular combination I'd asked about. That's like having your own research assistant, not a headstrong overconfident junior dev. Yes, they make mistakes, but at least now they'll admit to them. This is a long way from a year or two ago.

In conclusion: don't use an AI as one of your primary sources of information for technology you're new to, especially if you're not double-checking its answers like a good pilot.

This is like watching a carpenter blame their hammer because they didn’t measure twice. AI is a tool, it's like a power tool for a tradesperson: it'll amplify your skills, but if you let it steer the whole project? You’ll end up with a pile of bent nails.

LLMs are jittery apprentices. They'll hallucinate measurements, over-sand perfectly good code, or spin you in circles for hours. I’ve been there back in the GPT-4 days especially, nothing stings like realising you wasted a day debugging AI’s creative solution to a problem you could've solved in 20 minutes.

When you treat AI like a toolbelt, not a replacement for your own brain? Magic. It’s killer at grunt work like; explaining regex, scaffolding boilerplate, or untangling JWT auth spaghetti. You still gotta hold the blueprint. AI ain't some magic wand: it’s a nail gun. Point it wrong, and you’ll spend four days prying out mistakes.

Sucks it cost you time, but hey, now you know to never let the tool work you. It's hopefully a lesson OP learns once and doesn't let it sour their experience with AI, because when utilised properly, you can really get things done, even if it's just the tedious/boring stuff or things you'd spend time Google bashing, reading docs or finding on StackOverflow.

> AI is great for generating ideas or drafting code, but it doesn’t understand. It’s like giving a junior developer a chainsaw instead of a scalpel—it might finish the job, but you’ll spend twice as long cleaning up the mess.

For anything remotely complex, this is dead on. I use various models daily to help with coding, and more often than not, I have to just DIY it or start brand new chats (because the original context got overwhelmed and started hallucinating).

This is why it's incredibly frustrating to see VCs and AI founders straight-up gaslighting people about what this stuff can (or will) do. They're trying to push this as a "work killer," but really, it's going to be some version of the opposite: a mess creator that necessitates human intervention.

Where we're at is amazing, but we've got a loooong way to go before we can be on hover crafts sipping sodas Wall-E style.

I mean....

No design. Hardware & software. 2 different platforms. A new language. Zig. Unrealistic time expectations.

A senior SWE would've still tanked this, just in different ways.

Personally, I'd still consider it a valuable experiment, because the lessons learned are really valuable ones. Enjoy round 2 :)

The junior dev faking competence is useful but needs a lot of supervision (unlike a real junior dev we don't know if this one will get better).

the "AI lies" takeaway is way off for those actually using these tools. Calling it a "junior dev faking competence" is catchy, but misses the point. We're not expecting a co-pilot, it's a tool, a super-powered intern that needs direction. The spaghetti code mess wasn't AI "lying", it was a lack of control and proper prompting.

Experienced folks aren't surprised by this. LLMs are fast for boilerplate, research, and exploring ideas, but they're not autonomous coders. The key is you staying in charge: detailed prompts, critical code review, iterative refinement. Going back to web interfaces and manual pasting because editor integration felt "too easy" is a massive overcorrection. It's like ditching cars for walking after one fender bender.

Ultimately, this wasn't an AI failure, it was an inexperienced user expecting too much, too fast. The "lessons learned" are valid, but not AI-specific. For those who use LLMs effectively, they're force multipliers, not replacements. Don't blame the tool for user error. Learn to drive it properly.

> TLDR - AI isn’t a co-pilot; it’s a junior dev faking competence. Trust it at your own risk.

A junior dev faking competence while plagiarizing like crazy.

The plagiarizing part is why the junior dev from hell might not get fired: laundering open source copyrights can have beancounter alignment.