I don't know how other people work, but writing the code for me has been essential in even understanding the problem space. The architecture and design work in a lot of cases is harder without going through that process.
I recently had to build a widget that lets the user pick from a list of canned reports and then preview them in an overlay before sending to the printer (or save to PDF). All I knew was that I wanted each individual report's logic and display to be in its own file, so if the system needed to grow to 100 reports, it wouldn't get any more complicated than with 6 reports.
The final solution ended up being something like:
1. Page includes new React report widget.
2. Widget imports generic overlay component and all canned reports, and lets user pick a report.
3. User picks report, widget sets that specific report component as a child of the overlay component, launches overlay.
4. Report component makes call to database with filters and business logic, passes generic set of inputs (report title, other specifics, report data) to a shared report display template.
My original plan was for the report display template to also be unique to each report file. But when the dust settled, they were so similar that it made sense to use a shared component. If a future report diverges significantly, we can just skip the shared component and create a one-off in the file.
I could have designed all this ahead of time, as I would need to do with an LLM. But it was 10x easier to just start coding it while keeping my ultimate scalability goals in mind.
This. It’s also much easier to tell someone what you don’t like if what you don’t like is right in front of you than to tell them what you want without a point of reference.
100%! Lots of issues are only discovered when enough code has been written. More than that , other issues are discovered only when the project is actually deployed as MVP.
Additionally, the author seems to build an app just for the sake of building an app / learning, not to solve any real serious business problem. Another "big" claim on LLM capabilities based on a solo toy project.
YES YES YES!! I so wish that we could go back in time and never, ever have even suggested anything other that what you say here. AI doesn't do it for you. It does it with you.
You have to figure out what you want before the AI codes. The thinking BEFORE is the entire game.
Though I will also say that I use Claude for working out designs a lot. Literally hours sometimes with long periods of me thinking it through.
And I still get a ton more done and often use tech that I would never have approached before these glory days.
This. Code generation is cheap, so you can rapidly explore the space and figure out the architecture that best suits the problem. From there, I start fresh and pseudocode the basic pattern I want and have Claude fill in the gaps.
