For a while now, whenever I ve been building different apps, I ve often found myself feeling frustrated and a little scared somewhere in the middle of the process.
There s also another difficult phase that comes after building, especially when the product doesn t get the results you were hoping for. You start feeling disappointed, and thoughts like This is never going to work or No one is going to use this start creeping in.
Have you ever felt the same way? What helped you get through it, and how do you deal with these thoughts when they come up? :)
Imagine that you are about to join a startup (before raising funds) as a part-time employee. You are paid for work (compensation is like in any existing, well-established company in the industry, but you do not have regular employee benefits covering 401 plan, no equity, no health care plan, HO equipment fee, etc.)
You hope that after raising funds, you will become a full-time employee and receive benefits.
There are tons of apps based on GPT or other models launched every day, hard for individual to keep track of all of them. Yet, I bet many of them make your life easier. Which do you consider as most useful one and should get more attention? Since attention is all you need ;)
The speed at which AI generates code has officially surpassed our capacity to review it. For decades, the bottleneck in software engineering was writing the code. Today, the bottleneck has shifted entirely to trusting that the code can run effectively in production and actually solve the business problem. But let's be honest: humans never truly scaled code review anyway. Throughout my career, I have observed developers approving PRs or MRs that contain critical bugs. When they do engage in the review process, they often focus on stylistic issues. Why does this happen? Because reviewers are overloaded with their own backlogs to manage, and often choose the path of least resistance by saying, "Looks good to me." Now, we are trying to solve this by throwing AI at the problem! The Missed Reality: Code Review Wasn't Built for the AI Era Code review - whether conducted by a human or an LLM - was not designed for this era of autonomous coding. Code review does not actually verify whether the code accomplishes what was prompted, nor do they confirm that the code aligns with its intended specification or that an agent s "task completed" claim is deterministically true. Even a well-conducted review adhering to the 5-axes best practices (correctness, architecture, security, readability, and performance) falls short. Rarely does a code review verify that the original acceptance criteria were met or that the AI agent didn't deviate from the scope just to finish the PR. LLMs notoriously defer hard, multi-step, or dependent tasks, which means that the intent itself has diverged. Furthermore, reviewers rarely verify that test coverage was maintained or check if the AI agent quietly weakened the tests along the way to secure a passing PR. This leads to a critical question: Even if a human reviewer or an LLM could effectively manage all these new checks, can they realistically and deterministically do so given the massively increased speed of AI code generation? The solution? We have to move from opinion-based review to evidence-based verification. This means building guardrails (what I call the claim checker) that bind the original intent to deterministic evidence: ACs (intents) checks, the builds, the tests, the five-axis code review, the scans, the blast radius of the code change, the docs coverage, requirements are complete and don't contradict each other, and the monitoring coverage in the code. AI can advise. But only evidence should decide whether to merge or not! It s a shift we probably should have made years ago. But with agent loops writing code at machine speed, it is now the only way forward.
I keep running into the same confusion when I check in on any of my businesses after a day away. Nothing new in the inbox, no missed calls, the dashboard looks calm. Sometimes that calm means everything actually is fine. Other times it means nobody has noticed the thing that went wrong yet. From the outside those two look identical, quiet is quiet. The only way I have found to tell them apart is checking the activity underneath, not just the absence of alerts on top of it. Curious how the rest of you tell the difference, and whether you ever got burned trusting a quiet day that was not actually quiet.
•
