Building Software With LLMs: Do Not Trust Blindly, Verify

LLMs made software development more accessible for me. Not easier in the sense of "it does not matter anymore." Accessible in the sense that I could finally discuss, ask, read, change, and verify.

That is a big difference.

A model can write code. That is impressive, but it is not the real value. The real value is that it can explain code, find relationships, suggest small changes, and think about tests. It can help me enter a structure that would otherwise feel foreign.

At the same time, code is unforgiving. A beautiful sentence does not compile. A plausible explanation does not protect you from a bug. An agent can change one file cleanly and break something elsewhere. So AI-assisted development needs rules.

My most important rule: every change needs verification.

That can be a test. A build. A linter. A browser check. An API call. Sometimes just a focused review of the diff, if it is text or a small configuration. But there has to be some form of evidence. Otherwise it is wishful thinking.

The second rule: small steps beat big swings. If an agent changes ten files at once, it may be correct. But for beginners it is hard to review. A small change can be understood. It can be reverted. You learn from it.

The third rule: existing patterns matter more than personal taste. If a project already has a structure, AI should respect it. Not every problem needs a new abstraction, a new framework, or a large rename.

A non-technical person can still participate in this process. You do not have to review every line like a senior engineer. You can ask useful product questions. Does the button still do what it did before? Does the text fit on mobile? Does the login still work? Does the error message make sense? Does this change match the goal we gave the agent?

That kind of review matters. Software is not only code. It is behavior. If you can describe the expected behavior clearly, you can help guide the work. AI makes this easier because it can translate between human intent and technical change, but you still need to judge whether the outcome fits the intent.

The safest workflow I found is boring: ask for a small change, inspect the difference, run the check, then continue. When the AI says it is done, treat that as a claim, not a fact. A claim becomes useful when there is evidence behind it.

Public projects helped me turn this into practice. claude-code-hardened is about guardrails around agentic coding. ctxdesk explores AI-native ticket and project management with local model support. PaperCortex connects document intelligence with local AI. These are not separate hobbies. They are different answers to the same question: how do you make AI useful in real workflows without losing control?

For people without a software degree, responsibility can be intimidating at first. I made it smaller: I do not need to know everything. I need to know how to check. I need to know when to stop. I need to know which question helps next.

In normal words

Build means turning source code into something that can run.

Test means a repeatable check that something behaves as expected.

Linter means a tool that checks code for style and common mistakes before humans have to find them manually.

This is how real software emerges over time. Not from one perfect prompt, but from many small, verified steps.