And if so, in what work, and have you tried debugging issues with SOTA models?
From my experience it is certainly not the case that you cannot make progress after the first month.
I work on native mobile applications.
Without an active harness (eg. Appium) that can end-to-end deterministically verify the changes you make continue to work correctly it is almost impossible to continue to keep the same pace on the app.
Unsupervised LLMs (even fabel) are categorically incapable of running parallel unsupervised mobile app feature development.
That is my personal, first hand experience working in a team in this space.
What you are (I guess?) experiencing is user-in-the-loop light touch LLM development where you can 80% most tasks quite quickly (much faster than without assistance!) with a small number of human developers working on largely unrelated features and manually verifying they are correct and manually fixing the platform specific issues you encounter.
Maintaining a strong appium end-to-end test suite is still extremely challenging with notifications and maps.
Honestly, it blows my mind you could even being to claim that of all things, native apps using obscure languages like swift are suitable for this, compared to the much much easier path of web + react.
You might say “yeah yeah, but one month? Come on!”
…but have you actually seen how much code fabel can write in a month?
Its a lot.
So sure, you say, work at a slower pace. Don't just endlessly run a frontier model in unsupervised feature development mode.
Yes… you see, thats the point. Thats what the op is saying.
Move more slowly, and you can avoid building a spaghetti castle (ok sure! If you dont wanna, maybe don't retype every character by hand, but the point of that practice is not upping your wpm typing speed. :p It is to take the time to think, design and collaborate, not rush rush rush)
Anyway the author did address that
> Using LLMs this way allows me to work faster than not using LLMs at all, but I'm still slower than those who are willing to allow the machine to think for them. Instead of being 10x faster, I'm probably only 2x faster. But what I lose out on in terms of speed, I gain in terms of a deeper understanding of my code.
I also think I write better code than an LLM in certain areas, but in most programming domains, the LLM knows more than I do across many dimensions. As prompts get deeper, LLMs are already producing PhD-level code—and that's been shown in research. The vast majority of people don't have that level of education. Of course, having a PhD doesn't guarantee good coding, but at least it's clear that LLMs can handle that level of capability.
People might disagree, but my view is firm on this.
Remember that the quality of the LLMs code in the areas you don’t know is as good as the quality as the area you do know. You’re only able to gauge the quality of what you do know.
That's not true. You can follow the logic step by step, search for similar domains, and form a comparison group.
Realistically, if we take this logic to its conclusion, it's like asking: 'You're just a spectator, so can you really judge whether a football player is good at football?
Realistically, LLMs write code well. I'm a C# programmer, and as you know, the current trend in modern programming is to refine error handling—using try/catch at higher layers, working with monads, preserving computable contexts, and branching accordingly. That kind of code typically takes 1 to 2 hours of modeling before you even start writing.
But an LLM can do it in just 5 minutes.
So I think the opposite way: if LLMs can do this well in a domain I'm familiar with, they're probably just as capable in other domains too. And that makes them feel trustworthy.
And more importantly, no matter how great a human programmer is, once you step outside your domain, you're in unknown territory. In those areas, LLMs are surprisingly helpful.
Epistemologically, it might be true that you can't evaluate code in a domain you don't know. But people keep forgetting the fact that you can learn through that code. This very post is itself an example of learning through LLM-typed code.
And programming actually provides clearer results than many other domains. It's not based on subjective UX like UI design. You have:
1.Executable specifications
2.Performance measurements
3.Comparisons with official documentation
These are clear engineering outcomes that allow for objective comparison. For example, you can verify whether a program produces results within 5ms when executed.
Many epistemological arguments tend to overlook this.
A lot of code is open source. You can find mature implementations anywhere. Finding a repo from someone claiming 10 or 20 years of experience and running a differential comparison is not difficult at all."
Realistically, LLMs write code much better than most people. In my domain, there are areas where I still write better code than an LLM, especially when it comes to physical constraints it might not understand, but there are far more domains where the LLM writes much better code than I do. In that sense, writing code with an LLM and keeping track of it feels more helpful than I expected.
Practicing solo coding for an hour a day often ends up being mechanical and not very useful. This might actually be more helpful.
I don't remember if I read this advice or just intuited it myself (perhaps after some hard lessons), but it's a programming habit I've kept for as long as I can remember (I started coding in the 90s). If I feel rushed, e.g. someone looking over my shoulder, and I copy+paste something, it always leaves me with a sense of unease. It creates a memory & comprehension hole that sticks out like a sore thumb, even for seemingly simple snippets. You can't really be sure it's simple without stepping through it carefully, and simple can be deceptive because it's usually the interactions and assumptions wrt surrounding code that lead to surprises. Typing out code manually gives you time and space to consider the broader picture.
Typing itself is irrelevant, it is the timing spent, even if only seconds, pondering at what each word or syntactic element is and why use it.
Being slower does not automatically make you learn better, focus on the learning is what makes the difference.
If you don't have the opportunity to learn, the time to actually think, then a faster tool is not helping.
TL;DR: what matters is why you are doing something, is it solely to get the task done or is it primary to learn, or both?
The article is not wrong though that it pays off to have some imagination on how to use the models. For example, I want to use SIMD instructions in an ESP32-P4 CPU. Those instructions are undocumented for the most part, with just a couple of handwavey blog posts and some infuriatingly vague marketing material. So I just asked an LLM to create a `SIMD_P4.md` document with all the details. Lo and behold, it practically reverse-engineered the ISA. Now I can program in assembler by hand all I want and build that skill in my own brain, and whenever I find a slightly unclear op in the document, I ask the LLM to refine the documentation in that op.
The goal is to maintain the taste, for lack of a better word, that I've developed over decades of programming.
Claude put me on to the concept "Étude", so I've taken to calling it my Étude project.
Retyping things is inefficient for learning. It's like trying to retype calculus solutions — you don't learn from it. Even if there is an explanation of why the code is written in such a way, you did not come up with it, and you don't know alternative solutions. It is a practice for memorizing, not for building your intuition.
A better option is to write it yourself first and ask LLMs for better options. They are pretty good at it, especially when you need to optimize hot loops.
my workflow:
- ask not only for a solution to a problem but also for specific code (= tell the agent about your mental model of the codebase)
- ask for small stacked 'PRs/branches' and review/refactor heavily also using the agent (= refine your mental model of the codebase)
I don't think this is a practice which will be sustainable for very long
I ask it to plan the feature in a separate worktree.
In parallel I start coding without being biased by AI and vice versa.
At some point I read its plan and iterate on it all the while I am in implementation mode. This helps me improve my own vision.
Finally I ask the AI to review my implementation. It flags off bugs and gaps which are usually straightforward for it to fix.
If you write, you should write in your own words, to demonstrate your own understanding - the so-called Feynman technique. Never verbatim. That's as true for coding as it is for study notes.
These are good techniques as it causes your own brain to rapidly learn the material, but no matter how good it is I have never met anyone else that does it so the real ponderable is assuming that everyone else doesn't do this and what does that mean?
Mindlessly typing something is not much better than copy and pasting?
I could maybe see it if you asked it to spit out pseudocode you had to rewrite. At least there’s some translation there…
But this is bizarre. Write it yourself at that point. Is it any faster (or faster at all frankly) to prompt what you want, manually write it out, and maybe even make adjustments as you go? I’d argue not.
The way I wrote code in the past was to just first comment out what I wanted to do, and then underneath write the syntax for it. You could maybe do this too? Take the LLM code, and go through commenting what each section does to be able to effectively break it up? It still seems dumb.
I do think there is absolutely no way a learner should be using ai for code generation. I think code analysis is the only acceptable usecase.
Buy if you code for a job, good luck justifying this to management. “Yeah Claude already gave me the solution, I’ll take the rest of the week to type it out”
This is just a miserable career of "paint-by-number" because people can't be bothered to have a creative thought about their professional work or programming hobbies.
Software developers think that they are being clever with these kinds of strategies to "keep their skills sharp", but unfortunately the entire industry knows about this, and especially the upper management who are already eliminating these assembly line, JIRA-ticket-taker software jobs en masse.
I look at it this way: a technology has been introduced in the 2020s that has all but solved my RSI issues. So, for me, manually retyping LLM code sounds like insanity.
I understand the cognitive debt angle here but one of the things that comes with some experience is understanding the level of abstraction you're able to think effectively at.
daun_gee•57m ago
frankc•41m ago