Summarizer

You're not going crazy. That is what I see as well. But, I do think there is value in: - driving the LLM instead of doing it yourself. - sometimes I just can't get the activation energy and the LLM is always ready to go so it gives me a kickstart - doing things you normally don't know. I learned a lot of command like tools and trucks by seeing what Claude does. Doing short scripts for stuff is super useful. Of course, the catch here is if you don't know stuff you can't drive it very well. So you need to use the things in isolation. - exploring alternative solutions. Stuff that by definition you don't know. Of course, some will not work, but it widens your horizon - exploring unfamiliar codebases. It can ingest huge amounts of data so exploration will be faster. (But less comprehensive than if you do it yourself fully) - maintaining change consistency. This I think it's just better than humans. If you have stuff you need to change at 2 or 3 places, you will probably forget. LLM's are better at keeping consistency at details (but not at big picture stuff, interestingly.)

Same. This weekend, I built a Flutter app and a Wails app just to compare the two. Would have never done either on my own due to the up front boilerplate— and not knowing (nor really wishing to know) Dart.

I did the same thing but with react and supabase. I wouldn’t have done this on my own because of the react drudgery.

> - maintaining change consistency. This I think it's just better than humans. If you have stuff you need to change at 2 or 3 places, you will probably forget. LLM's are better at keeping consistency at details (but not at big picture stuff, interestingly.) I use Claude Code a decent amount, and I actually find that sometimes this can be the opposite for me. Sometimes it is actually missing other areas that the change will impact and causing things to break. Sometimes when I go to test it I need to correct it and point out it missed something or I notice when in the planning phase that it is missing something. However I do find if you use a more powerful opus model when planning, it does consider things fully a lot better than it used to. This is actually one area I have been seeing some very good improvements as the models and tooling improves. In fact, I actually hope that these AI tools keep getting better at the point you mention, as humans also have a "context limit". There are only so many small details I can remember about the codebase so it is good if AI can "remember" or check these things. I guess a lot of the AI can also depend on your codebase itself, how you prompt it, and what kind of agents file you have. If you have a robust set of tests for your application you can very easily have AI tools check their work to ensure things aren't being broken and quickly fix it before even completing the task. If you don't have any testing more could be missed. So I guess it's just like a human in some sense. If you have a crappy codebase for the AI to work with, the AI may also sometimes create sloppy work.

I tend to be surprised in the variance of reported experiences with agentic flows like Claude Code and Codex CLI. It's possible some of it is due to codebase size or tech stack, but I really think there might be more of a human learning curve going on here than a lot of people want to admit. I think I am firmly in the average of people who are getting decent use out of these tools. I'm not writing specialized tools to create agents of agents with incredibly detailed instructions on how each should act. I haven't even gotten around to installing a Playwright mcp (probably my next step). But I've: - created project directories with soft links to several of my employer's repos, and been able to answer several cross-project and cross-team questions within minutes, that normally would have required "Spike/Disco" Jira tickets for teams to investigate - interviewed codebases along with product requirements to come up with very detailed Jira AC, and then,.. just for the heck of it, had the agent then use that AC to implement the actual PR. My team still code-reviewed it but agreed it saved time - in side projects, have shipped several really valuable (to me) features that would have been too hard to consider otherwise, like... generating pdf book manuscripts for my branching-fiction creating writing club, and launching a whole new website that has been mired in a half-done state for years Really my only tricks are the basics: AGENTS.md, brainstorm with the agent, continually ask it to write markdown specs for any cohesive idea, and then pick one at a time to implement in commit-sized or PR-sized chunks. GPT-5.2 xhigh is a marvel at this stuff. My codebases are scala, pekko, typescript/react, and lilypond - yeah, the best models even understand lilypond now so I can give it a leadsheet and have it arrange for me two-hand jazz piano exercises. I generally think that if people can't reach the above level of success at this point in time, they need to think more about how to communicate better with the models. There's a real "you get out of it what you put into it" aspect to using these tools.

> To be fair, I was able to get it to work pretty well after giving it extremely detailed instructions and monitoring the "thinking" output and stopping it when I see something wrong there to correct it, but at that point I felt silly for spending all that effort just driving the bot instead of doing it myself. This is the challenge I also face, it's not always obvious when a change I want will be properly understood by the LLM. Sometimes it one shots it, then others I go back and forth until I could have just done it myself. If we have to get super detailed in our descriptions, at what point are we just writing in some ad-hoc "programming language" that then transpiles to the actual program?

I’m trying to pivot my career from web/business app dev entirely into embedded, despite the steep learning curve, many new frameworks and tool chains, because I now have a full-time infinitely patient tutor, and I dare say it’s off to a pretty good start so far.

If it’s okay with you, I’m going to very intentionally do my initial learning on mainstream hardware before moving on to anything beyond that.

I’ve had the same experience with the recent batch of candidates for a Junior Software Engineer position we just filled. Their projects looked impressive on the surface and seemed very promising. Once we got them into a technical screening, most fell apart writing code. Our problem was simple: using your preferred programming language, model a shopping cart object that has the ability to add and remove items from the cart and track the cart total. We were shocked by how incapable most candidates were in writing simple code without their IDEs tab completion capability. We even told them to use whatever resources they normally used. The whole experience left us a little surprised.

I think it’s just very alien in that things which tend to be correlated in humans may not be so correlated in LLMs. So two things that we expect people to be similarly good at end up being very different in an AI. It does also seem to me that there is a lot of variance in skills for prompting/using AI in general (I say this as someone who is not particularly good as far as I’m aware – I’m not trying to keep tips secret from you). And there is also a lot of variance in the ability for an AI to solve problem of equal difficulty for a human.

Frankly, it sounds like you have a lot to learn about agentic coding. It’s hard to define exactly what makes some of us so good at using it, and others so poor, but agentic coding has been life changing for myself and the folks I’ve tutored on its use. We’re all using the same tools, but subtle differences can make a big difference.

> it's incredibly obvious that while these tools are surprisingly good at doing repetitive or locally-scoped tasks, they immediately fall apart when faced with the types of things that are actually difficult in software development and require non-trivial amounts of guidance and hand-holding to get things right I used this line for a long time, but you could just as easily say the same thing for a typical engineer. It basically boils down to "Claude likes its tickets to be well thought out". I'm sure there is some size of project where its ability to navigate the codebase starts to break down, but I've fed it sizeable ones and so long as the scope is constrained it generally just works nowadays

The difference is a real engineer will say "hey I need more information to give you decent output." And when the AI does do that, congrats, the time you spend identifying and explaining the complexity _is_ the hard time consuming work. The code is trivial once you figure out the rest. The time savings are fake.

Why aren't you cut out? It's a skill that takes practice -coordinating disparate people and groups, creating communication where you notice they're not talking to each other, creating or fixing processes that annoy or cause chaos if they're not there, encouraging people, being a therapist, seeing what's not there and pushing a vision while you get the group to go along, protecting people from management above and pressures around, etc are mostly skills that you learn. Sometimes no one will give you feedback so you have to figure it out yourself (unless you're lucky to get a mentor), so you just have to throw yourself in and give yourself grace to fail and succeed over time. The only skill of these I think is possibly genetic or innate, is being able to see the big picture and make strategical decisions. A lot of tech people skew cognitively in narrow areas, and have trouble conceptualizing the world beyond. One challenge here is the ubiquitous 'managers just approve vacations and waste space' sentiment on here and in some places. These people are a chore to manage (and sometimes are better not being present in your group).

My 15 year old son has been building his own video games with Unreal Engine for a few years.. I was recently looking for mentors to work with him and advance his skills, targeting college aged kids / young 20s.. It was surprising to me how many people I came across in this field at this young age that are trying to focus on the "higher level" game planning aspects and not so much on the lower level implementation specifics.

I highly recommend the Handmade Hero series to folks in his situation. Casey has put up an absurd amount of material for everyone for free. https://www.youtube.com/playlist?list=PLnuhp3Xd9PYTt6svyQPyR... https://guide.handmadehero.org/hmcon/ https://guide.handmadehero.org/ https://handmade.network/forums

You’re right, but on the other hand once you have a basic understanding security, architecture, etc you can prompt around these issues. You need a couple of years of experience but that’s far less then the 10-15 years of experience you needed in the past. If you spend a couple of years with an LLM really watching and understanding what it’s doing and learning from mistakes, then you can get up the ladder very quickly.

I find that security, architecture, etc is exactly the kind of skill that takes 10-15 years to hone. Every boot camp, training provider, educational foundation, etc has an incentive to find a shortcut and we're yet to see one. A "basic" understanding in critical domains is extremely dangerous and an LLM will often give you a false sense of security that things are going fine while overlooking potential massive security issues.

Then, in my opinion, there's nothing revolutionary about it (unless you learned something, which... no one does when they use LLMs to code)

I am an old school c++ programmer and actually I have learned modern c++ just by using LLMs.

skill issue

I admire the people that can live happily in the ignorance of what’s under the hood, in this case not even under the layer of claude code because that was too much aparently so people are now putting openclaw+telegram on top of that. And me ruining my day fighting with a million hooks, specs and custom linters micromanaging Claude Code in the pursuit of beautiful code.

That's a different problem and not really relevant to OpenClaw. Also, your issue is primarily a skills issue (your skills) if you're using one of the latest models on Claude Code or Codex.

I beg to differ, and so do a lot of other people. But if you're locked into this mindset, I can't help you. Also, Codex isn't a model, so you don't even understand the basics. And you spent "several hours" on it? I wish I could pick up useful skills by flailing around for a few hours. You'll need to put more effort into learning how to use CLI agents effectively. Start with understanding what Codex is, what models it has available, and which one is the most recent and most capable for your usage.