Understanding existing code or generating possible solutions is getting easier. The hard part is still deciding what to build, what not to build, and how independent ideas fit together into something coherent.
In my experience, AI reduced the cost of implementation far more than it reduced the cost of synthesis.
I'm not quitting, but AI has completely changed my priorities.
Building software has become dramatically easier over the last year. The hard part is no longer creating products—it's getting people to discover and trust them.
I spend far more time thinking about distribution today than implementation. That's a shift I didn't expect.
Conventional commits (especially with git emojis) show at a glance the blast radius of the change (eg whether it breaks the product itself or just some internal dev tools). Emojis help immensely when looking at dozens of commits at a time.
That information should still be in the commit messages. "No functional change intended." appears widely in FreeBSD commit logs when code is being refactored (or, rarely, restyled).
And the issue isn't whether you can remember what you changed yesterday; this is largely about making sure other developers can quickly identify relevant commits. If you're a solo non-OSS developer, this is entirely relevant to you.
> Interviews are useful, but the ability to ship, maintain and improve real projects should probably carry more weight.
But how do you assess this? Maybe we should get them to write a document that details what they've done, and then invite them to a conversation to discuss it.
The parallel agents concept is interesting. How does it handle state sync between agents when they're modifying the same board? Or is there built-in conflict resolution?
Interesting approach. The unified pricing table is helpful, but I'd love to see latency benchmarks across providers – that's often the hidden cost beyond price/token.
Tested the Nako IDE - got "hello world" running! But I'm
a bit confused about the architecture.
Is Waputer a full OS kernel or primarily a dev environment?
The three components (School/Terminal/Editor) seem related
but I can't quite connect the dots.
What's the typical workflow - write in Nako → WASM → run
where exactly?
Cool concept, just trying to understand the pieces!
Thank you for checking it out, and I am glad you are interested! You are right in that some bits are still needed to fully close the loop. The short of it: the idea is to write apps in Nako, compile it to WASM, and then publish it to run on Waputer.
The longer answer is that Waputer has a package system that Nako will soon take advantage of. NakoIDE itself is just a package that gets loaded when you go to the URL. The APIs for creating packages and allowing others to run them already exist; I have not had time to document them or integrate them directly into Nako. Users will be able to directly publish to URLs of the form "waputer.app/@user/package", while main applications like Nako exist just as "waputer.app/package". I will have a blog post that digs into the details of packages and publishing in a few weeks.
I also want to emphasize that I do not require everything end up on Waputer. The compiler that is running inside NakoIDE generates WASM files by default, but it can output x86_64 object files. I love interoperability.
Building is cheap. Distribution, differentiation and discovering unmet demand are becoming the expensive parts.