It just doesn't work. I'm trying to build a simple tool that will let me visualize grid layouts.
It needs to toggle between landscape/portrait, and implement some design strategies so I can see different visualizations of the grid. I asked it to give me a slider to simulate the number of grids.
1st pass, it made something, but it was squished. And toggling between landscape and portrait made it so it squished itself the other way so I couldn't even see anything.
2nd pass, syntax error.
3rd try I ask it to redo everything from scratch. It now has a working slider, but the landscape/portrait is still broken.
4th try, it manages to fix the landscape/portrait issue, but now the issue is that the controls are behind the display so I have to reload the page.
5th try, it manages to fix this issue, but now it is squished again.
6th try, I ask it to try again from scratch. This time it gives me a syntax error.
This is so frustrating.
You need to be reasonably experienced and guide it.
First, you need to know that Claude will create nonsensical code. On a macro level it's not exactly smart it just has a lot of contextual static knowledge.
Debugging is not it's strongest skill. Most models don't do good at all. Opus is able to one-shot "troubleshooting" prompts occasionally, but it's a high probability that it veer of on a tangent if you just tell it to "fix things" based on errors or descriptions. You need to have an idea what you want fixed.
Another problem is that it can create very convincing looking - but stupid - code. If you can't guide it, that's almost guaranteed. It can create code that's totally backwards and overly complicated.
If it IS going on a wrong tangent, it's often hopeless to get it back on track. The conversation and context might be polluted. Restart and reframe the prompt and the problems at hand and try again.
I'm not totally sure about the language you are using, but syntax errors typically happens if it "forgets" to update some of the code, and very seldom just in a single file or edit.
I like to create a design.md and think a bit on my own, or maybe prompt to create it with a high level problem to get going, and make sure it's in the context (and mentioned in the prompts)
Like trying to write with a wet noodle - always off in some way.
Write the code feels way more precise and not less efficient.
https://ai-lint.dosaygo.com
While this may be possible, it likely requires a very detailed prompt and/or spec document.
---
Here is an example of something I successfully built with Claude: https://rift-transcription.vercel.app
Apparently I have had over 150 chat sessions related to the research and development of this tool.
- First, we wrote a spec together: https://github.com/Leftium/rift-transcription/blob/main/spec...
- The spec broke down development into major phases. I reviewed detailed plans for each phase before Claude started. I often asked Claude to update these detailed plans before starting. And after implementation, I often had to have Claude fix bugs in the implementation.
- I tried to share the chat session where Claude got the first functional MVP working: https://opncd.ai/share/fXsPn1t1 (unfortunately the shared session is truncated)
---
"AI mistakes you're probably making": https://youtu.be/Jcuig8vhmx4
I think the most relevant point is: AI is best for accelerating development tasks you could do on your own; not new tasks you don't know how to do.
---
Finally: Cloudlflare builds OAuth with Claude and publishes all the prompts: https://hw.leftium.com/#/item/44159166
https://github.com/lawless-m/Devolver
it uses hooks to export the session
https://github.com/lawless-m/Devolver/blob/master/HOOKS.md
and then parses the session logs and dumps them out
https://github.com/lawless-m/Devolver/blob/master/JSONL_FORM...
I then have it go to a central location because I use multiple machines and it creates a website so I can see what I've been working on.
Reading these figures now, I think it counts its own prompts, you know it talks to itself. There's no way I've typed ten thousand prompts on that projectDead Comment
Lord help us
Like OP, I've been similarly struggling to get as much value from CC (grok et c) as "everyone" else seems to be.
I'm quite curious about the workflow around the spec you link. To me, it looks like quite an extensive amount of work/writing. Comparable or greater than the coding work, by amount, even. Basically trading writing code files for writing .md files. 150 chat sessions is also nothing to sneeze at.
Would you say that the spec work was significantly faster (pure time) than coding up the project would have been? Or perhaps a less taxing cognitive input?
(I also implemented the previous version with only a high-level, basic understanding of websockets: https://rift-transcription.vercel.app/sherpa)
I think of Claude like a "force-multiplier."
I have been able to implement ideas I previously gave up on. I can test out new ideas much faster.
For example, https://github.com/Leftium/gg started out as 100% hand-crafted code. I wanted gg to be able to print out the expression in the code in addition to the value like python icecream. (It's more useful to get both the value and the variable name/expression.) I previously tried, and gave up. Claude helped me add this feature within a few hours.
And now gg has its own virtual dev console optimized for interacting with coding agents. A very useful feature that I would probaly not have attempted without Claude. It's taken the "open in editor" feture to a completely new level.
I have implemented other features that I would have never attempted or even thought about. For example without Claud's assistance https://ws.leftium.com would not have many features like the animated background that resembles the actual sky color.
60 minute forecast was on my TODO list for a long time. Claude helped me add it within an afternoon or so.
Note: depending on complexity of the feature I want to add the spec varies in the level of detail. Sometimes there is no spec outside Claude's plans in the chat session.
[1]: https://github.com/gruns/icecream
In my experience, trying to make a plan/specs that really match what I want often ends in a struggle with Claude trying to regress to the mean.
Also it’s so easy to write code that I always have tons of ideas I end up implementing that diverge from the original plan…
- It was definitely not one CC session. In fact, this spec is a spin-off of several other specs on several other branches/projects.
- I've actually experienced quite the opposite: I suggest an idea for the spec and Claude says "great idea!" Then I change my mind and go in the opposite direction: "great idea!" again. Once in a while, I have to argue with Claude to get my idea implemented (like adding dependencies to parse into a proper AST instead of regex.)
- One tip: it's very useful to explain the "why" to Claude vs the "what." In fact, if you just explain the why/problem without a specific solution, Claude's suggestions may surprise you!
Deleted Comment
Yes, this is what the hype says doesn't it?
Or... are they all lying?
A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly: “You cannot fix a machine by just power-cycling it with no understanding of what is going wrong.”
Knight turned the machine off and on.
The machine worked.
http://www.catb.org/jargon/html/koans.html
Your first one-shot might be a good rough prototype. From there, you continue the conversation with your refinements. While Claude goes and works on that for 15 minutes - you can go and do other work. Or talk with another Claude in another window to make progress on another project.
A good mental model is to imagine you're talking to a remote developer. You need to give them an extremely detailed spec on the first go if you expect them to get it right the first time. Sometimes it's better to explain "this is my grand vision, but how about we first mockup a prototype to see if that's actually how I want it to work". Sometimes Claude will suggest you talk about your plan together first to remove the ambiguities from the plan, or you can encourage Claude to do that with you.
(Also, the remote developer mindset is useful - treat the remote developer with respect, with humanity, and they're more likely to be helpful towards you and motivated to align with your goals.)
Consider that in an hour or two of conversation, you now have your app, completed, fully debugged... and not once did you look at the code, and you spent half of that time catching up on your other tasks. That's vibe coding.
Dead Comment
It seems you try to tell the tool to do everything in one shot. That is a very wrong approach, not just with Claude but with everything(you ask a woman for a date and if you do not get laid in five minutes you failed?). When I program something manually and compiles, I expect it to be wrong. You have to iron it and debug it.
Instead of that:
1.Divide the work in independent units. I call this "steps"
2.Subdivide steps into "subsets" You work in an isolated manner on those subsets.
3.Use an inmediate gui interface like dear imgui to prototype your tool. Translating then into using something else once it works is quite easy of LLMs.
4.Visualize everything. You do not need to see the code but you need to visualise every single thing you ask it to do.
5.Tell Claude what you want and why you want it and update the documentation constantly.
6. Use git in order to make rock solid steps that Claude will not touch when it works and you can revert changes or ask the ia to explore a branch, explaining how you did something and want something similar.
7. Do not modify code that already works rock solid. Copy it into another step leaving the step as reference and modify it there.
5.Use logs. Lots of logs. For every step you create text logs and you debug the problems giving Claude the logs to read them.
6.Use screenshots. Claude can read screenshots. If you visualise everything, clause can see the errors too.
7.Use asserts, lots of asserts, just like with manual programming.
It is not that different from managing a real team of people...
If successfully using Claude Code is as difficult as successful dating, I'm not sure this tech will prevail. ;)
Stuff like "divide the work up" is something you do when doing it yourself. Making a GUI prototype isn't really much work at all in the age of LLMs, akin to drawing up a few ideas on a notepad. Using git for small steps is something lots of people do for their own work and rebase later. Using extensive logging is mostly just something you have in your AGENTS.md for all your projects and forget about, similarly getting it setup to make and look at screenshots.
What part of this is more work than doing it yourself?
Documentation. Comments. Writing a plan and/or a spec before you begin coding. Being smart with git commits and branches.
In about 2 weeks we have a functional game, 60 levels, 28 different types of enemies, a procedurally generated daily challenge mode, an infinity mode. Tower crafting and upgrades, an economy system in the game for pay for the upgrades.
This likely would have taken us months to get to the point that we are at, it was playable on Day 2.
Put that down! What are you doing? Don't put that in your mouth. Where are you going? Stop that! Why are you sitting there alone, Johnny?
However ChatGPT is really helpful doing sysadmin style tasks on Linux.
You haven't even said what programming language you're trying to use, or even what platform.
It sounds to me like you didn't do much planning, you just gave it a prompt to build away.
My preferred method of building things, and I've built a lot of things using Claude, is to have a discussion with it in the chatbot. The back and forth of exploring the idea gives you a more solid idea of what you're looking for. Once we've established the idea I get it to write a spec and a plan.
I have this as an instruction in my profile.
> When we're discussing a coding project, don't produce code unless asked to. We discuss projects here, Claude Code does the actual coding. When we're ready, put all the documents in a zip file for easy transfer (downloading files one at a time and uploading them is not fun on a phone). Include a CONTENTS.md describing the contents and where to start.
So I'll give you this one as an example. It's a Qwen driven System monitor.
https://github.com/lawless-m/Marvinous
here are the documents generated in chat before trying to build anything
https://github.com/lawless-m/Marvinous/tree/master/ai-monito...
At this point I can usually say "The instructions are in the zip, read the contents and make a start." and the first pass mostly works.
The LLM under the hood is essentially a very fancy autocomplete. This always needs to be kept in mind when working with these tools. So you have to focus a lot on what the source text is that’s going to be used to produce the completion. The better the source text, the better the completion. In other words, you need to make sure you progressively fill the context window with stuff that matters for the task that you’re doing.
In particular, first explore the problem space with the tool (iterate), then use the exploration results to plan what needs doing (iterate), when the plan looks good and makes sense, only then you ask to actually implement.
Claude’s built in planning mode kind of does this, but in my opinion it sucks. It doesn’t make iterating on the exploration and the plan easy or natural. So I suggest just setting up some custom prompts (skills) for this with instructions that make sense for the particular domain/use case, and use those in the normal mode.
Two questions:
1. How are you using Claude? Are you using https://claude.ai and copying and pasting things back and forth, or are you running one of the variants of Claude Code? If so, which one?
2. If you're running Claude Code have you put anything in place to ensure it can test the code it's writing, including accessing screenshots of what's going on?
Good luck!
It will ask you questions, break down the project into smaller tasks, work through them one by one with UAT check points along the way.
It also handles managing your context