| Previously: https://news.ycombinator.com/item?id=47195123 (March 2026, 136 comments) Several months ago I posted about my little proto-app, Now I Get It! that uses LLMs to translate scientific papers into web pages that anyone can understand. The feedback and engagement from this community was terrific and helped me turn it into a real product. It's a niche, convenience product. Not a game changer. I'm comfortable with that and went into it with eyes wide open. Regardless of whether the product does anything, building and launching this as a solopreneur was super fun and educational. It helped me hone my agentic engineering skills and also gave me a better sense of what I could truly delegate to coding agents and where I had to be involved. In short, my experience led me to believe that the best models, harnesses, and techniques aren't yet there to fully build a cloud-native app (AWS) that is fast, cost-efficient, robust, and secure. Not to mention modular and extensible. The number of decisions a human must make is still very high. That's not a huge surprise to me since coding is just one part of engineering. The fun part of engineering (for me at least) is putting shape to a problem and thinking at a systems level even when decomposing into tasks. It's the constant zoom-in, zoom-out interplay that first attracted me to software engineering. Yes, I rely heavily on LLMs for development but 9/10 times I would find something wrong in a plan, a design, an implementation, or a test that would have created problems if I wasn't there. The process I followed for this build, in-a-nutshell:
1. Every feature, bug, and improvement gets its own Issue. Descriptions are sparse so the LLM can really dig into during planning.
2. Plan every issue but override Claude Code's planning mode since it tries to implement immediately after a plan is approved. Also, it's helpful to have the LLM write a user story before writing the plan so that UX stays front-and-center. I had so many issues where Claude would be like, "Oh. You mean you don't want the user to see a 403?"
3. Read the plan.
4. Decompose into Beads (Thanks Steve).
5. Open a new Claude Code session in TMUX and say, switch to a worktree for issue xyz and build it.
6. Deploy to a test AWS environment. Use Claude for Chrome to do a first-pass check for front-end stuff then I'd follow up.
7. Devlog the work.
8. Make a PR, review, merge, deploy to prod Three things I did early on that turned out to be very useful:
1.
The app was free when I first posted and people from around the world processed a lot of papers. This gave me a TON of data I could analyze to figure out a pricing structure that maintains a sustainable margin. This is important because the app is self-funded; I don't want to have to decommission it because I miscalculated my expenses. 2.
Optimized architecture for low idle cost. I don't want a bunch of infrastructure burning a hole in my bank account if I can't get enough customers to sustain the app. This app relies heavily on static html pages on S3 behind CloudFront, along with Lambda, and DynamoDB. All very cost-effective. 3.
In addition to my DevLog skill, I made an app-specific skill called now-i-blog-it. This reviews my DevLog for recent updates and writes short, technical blog posts. Of course, LLMs aren't great writers so I wound up with another skill called cringelinter that can be run in a Ralph loop to scrub all the mic-drops, bro-speak, and cringe words from the blogs. The blog has over 60 entries so far covering everything from architecture, to adding an inline HTML and KaTeX editor, to my first hacker, to launch. Some of you may find it interesting. It demonstrably shows that that reports of the death of software engineering have been greatly exaggerated. Thanks again to this community for engaging with my original post. It's been a fun build. |