DEV Community: Ntty

Stop Treating Your LLM Agent Like a Black Box

Ntty — Mon, 07 Sep 2026 11:00:24 +0000

We are building a lot of agents right now. The demos are flashy. The code, however, is often a mess of recursive prompts and hope.

I spent the last month debugging an autonomous support bot for a mid-sized SaaS company. The agent was supposed to read ticket threads, check the user's billing status, and draft a response. In the demo, it worked perfectly. In production, it hallucinated refunds, ignored context, and occasionally tried to delete the user's account. It was a nightmare.

The problem wasn't the model. The problem was that we treated the agent like a magic box. We sent data in, we got text out, and we assumed the internal reasoning was sound. It wasn't. It was just probability guessing with high confidence.

If you are building agentic systems, you need to stop treating them as "AI" and start treating them as fragile, stateful software. Here is what I learned the hard way.

The State is the Bug

Most agent frameworks hide the state. They manage the conversation history, the tool calls, and the current step for you. This feels nice until something breaks. When it breaks, you have no idea what the agent "thought" at step 3 of its 10-step process.

I had to refactor our entire pipeline to expose the internal state. Every decision the agent made was logged. Not just the final output, but the intermediate reasoning. When the agent decided to call the check_billing tool, we logged why it made that choice. When it decided to stop, we logged the termination condition.

This turned our debugging session from a guesswork session into a code review. We found that the agent was getting confused by contradictory information in the ticket history. It wasn't a model failure; it was a data cleaning failure. The state log revealed the exact point where the confusion started.

Expose the Tools, Not Just the Model

Agents are only as good as their tools. A common mistake is giving an agent a generic execute_code tool. It is powerful, but it is also dangerous. The agent can do anything, which means it can break everything.

We replaced the generic tool with specific, narrow tools. get_invoice, update_ticket_status, send_email_draft. Each tool had strict input validation. If the agent tried to send an email with a subject line longer than 100 characters, the tool rejected it. The agent then had to adapt.

This constraint is key. If you give an agent too much freedom, it will find ways to fail that you never anticipated. By narrowing the scope of what it can do, you make the failure modes predictable. You can test them. You can fix them.

Determinism is a Feature

We used to think that randomness was a feature of LLMs. It is not. It is a liability in a production system. An agent that behaves differently every time it runs the same task is not reliable. It is a coin flip.

We started using lower temperatures for the reasoning steps. It made the agent less creative, but it made it consistent. We also added a retry loop with a specific failure condition. If the agent failed to parse the output of a tool, it would retry up to three times. If it still failed, it would escalate to a human.

This sounds boring. It is not. It is the difference between a toy and a product. Users do not care if your agent is "creative." They care if it works the same way every time.

The Human in the Loop is Not a Fallback

Too many teams treat human intervention as a last resort. "Let the agent try, and if it fails, a human will fix it." This is a bad model. The human review should be part of the workflow from the start.

We designed our agent to mark low-confidence actions. If the agent was not sure about a billing dispute, it would flag it for review before sending the email. This reduced our error rate by 40%. It also gave us a dataset of edge cases that we could use to improve the prompts later.

The human is not a backup plan. The human is a quality control step. Treat it that way, and your agent will be more robust.

Takeaway

Agentic systems are not magic. They are software. They have bugs. They have state. They have edge cases. You need to debug them like any other piece of code. Log everything. Constrain the tools. Prioritize consistency over creativity. And keep a human in the loop where it matters.

The next time your agent does something weird, do not blame the model. Look at the state. Look at the tools. Look at the logic. You will find the bug. It is there. It is just hidden behind the veil of "AI." Lift the veil, and you will see the code. And code you can fix.

Stop Building Features Nobody Asked For

Ntty — Sun, 06 Sep 2026 11:00:33 +0000

I spent three months building a feature I thought was obvious. A complex reporting dashboards for a niche project management tool. I optimized the queries. I built the UI. I wrote the tests. I pushed it to production on a Friday.

By Monday, the metrics were flat. Not negative, just flat. The feature sat there, unused. I had solved a problem that existed in my head, not in my users' workflows.

This is the most common killer of early-stage SaaS products. It is not bad code. It is not a slow server. It is a mismatch between what you build and what people actually need. And it is almost always preventable.

The Roadmap Trap

Most developers start a SaaS project with a list of features. We think in terms of technical capabilities. "I will build a user authentication system." "I will add Stripe integration." "I will create a CSV export."

This is backward.

A roadmap based on features is a roadmap based on your ego. It tells you what you want to show off. It does not tell you if anyone will pay for it. When you start coding based on a feature list, you have already made the biggest architectural decision: you have decided that the problem is worth solving. But you have not validated that assumption.

Validation Before Code

Before you write a single line of production code, you need to know if the pain is real. This sounds simple, but it is hard to do when you are excited about the tech stack.

Talk to your target users. Not potential users. Not friends. Actual people who are currently struggling with the problem you want to solve. Ask them how they handle it today. Ask them what they have tried. Ask them what that costs them in time or money.

If they do not have a current, manual, or painful workaround, the problem is likely not urgent enough to sustain a SaaS business. People will pay to remove pain. They will not pay to add complexity for the sake of novelty.

The One-Week Sprint

Once you have identified a real pain point, do not build the full solution. Build the smallest thing that addresses that specific pain.

This is often called an MVP, but that term is overused and misunderstood. An MVP is not a product with missing features. It is a hypothesis test.

Can you solve that one specific problem in one week? If not, the problem is too complex, or you do not understand it well enough. A real MVP for a SaaS tool might be a simple script, a no-code backend, or even a manual service where you do the work for them behind the scenes.

The goal is to get value to the user as fast as possible. If you can automate the process later, great. But first, prove that the process is worth automating.

Listening to Silence

The most valuable feedback in SaaS development is often silence.

If you ship a feature and nobody complains, nobody praises it, and nobody uses it, that is a signal. Silence means indifference. Indifference is worse than negative feedback. Negative feedback tells you what is wrong. Indifference tells you that what you built does not matter enough to care.

When you get silence, do not keep building more features on top of it. That is like stacking bricks on a shaky foundation. Step back. Go back to the users. Ask them directly: "What are you doing with this tool? What is stopping you from using it more?"

You will likely find that the feature you built was the wrong feature. Or that it was the right feature, but it was missing one critical piece of context. Or that the onboarding flow was confusing them before they even saw the value.

The Feedback Loop

Successful SaaS developers do not build in long, isolated sprints. They build in tight loops.

Identify a pain point.
Build a tiny solution.
Ship it to a small group of real users.
Observe behavior, not just opinions.
Iterate or pivot.

This loop should take days, not months. If your iteration cycle is longer than a week, you are too far from your user. You are guessing. And in SaaS, guessing is a luxury you cannot afford.

A Concrete Takeaway

Next time you are about to start coding a new feature, pause. Ask yourself: Who is this for? What specific task are they trying to complete? How are they doing it today? Is there a way to solve this in less than a week?

If you cannot answer those questions clearly, you are not ready to code. You are ready to talk. Go talk to a user. Write down their words. Build to their words, not to your assumptions.

The code will always be there. The opportunity to solve a real problem might not be.

Save yourself the heartbreak of shipping an unused feature. Validate first. Build second. Iterate fast. That is how you build a SaaS that people actually want to use.

How to Stop Fighting Your AI Coding Assistant

Ntty — Thu, 03 Sep 2026 11:00:56 +0000

I used to hate AI coding assistants. They felt like talking to a junior developer who had read the documentation once and forgot the rest. You ask for a complex system design, and they give you a for loop and a comment that says "// add error handling here."

Then I changed how I talked to them. The tool didn't change. My expectations and my prompt structure did.

The biggest mistake most developers make is treating the AI as an oracle. You throw a vague request at it, wait for the magic, and get annoyed when the result is generic. AI assistants are not oracles. They are probabilistic text generators. They do not know your codebase unless you show them. They do not know your architectural preferences unless you state them.

Here is how I structure my workflow to get usable, production-ready code from an AI assistant.

Context is King

Never start a conversation with "Write a function to parse JSON." That is useless. Instead, start by defining the environment.

"I am building a Node.js backend using Express. I need a middleware function to parse JSON bodies. The application uses TypeScript. Error handling should follow the standard Express error middleware pattern. Return the code."

See the difference? The first prompt allows the AI to guess. It might give you Python. It might use async/await in a way that conflicts with your code. The second prompt constrains the output. The AI cannot hallucinate a Python solution because you explicitly told it the environment is Node.js and TypeScript.

Break It Down

Do not ask for the whole feature in one go. If you need a REST API for user management, do not say "Build me a user API." That is a project, not a prompt.

Break it into steps:

"Design the database schema for a user table with email, password hash, and created_at. Use PostgreSQL syntax."
"Write a TypeScript interface for the User model based on that schema."
"Write an Express route that accepts a POST request to create a user. Validate the input using Joi."

By breaking it down, you can review each step. If the schema is wrong, you catch it before writing the routes. If the validation logic is flawed, you fix it before wiring it to the controller. This is just like code review, but faster.

Provide Examples

AI assistants are exceptionally good at pattern matching. If you show them a pattern you like, they will follow it.

"Here is how we structure our API responses in this project: { data: ..., error: null }. Write a GET endpoint for /users/:id that follows this structure."

Paste a snippet of your existing code. Show them how you name your variables. Show them how you handle logging. The AI will mimic your style. This is the secret to making the code feel like you wrote it. Without examples, the code feels like an outsider wrote it. With examples, it blends in.

Constrain the Output

Tell the AI what it should NOT do.

"Do not use any external libraries. Only use standard Node.js modules."

"Do not write tests. Just focus on the implementation."

"Keep the function under 20 lines."

Negative constraints are powerful. They prevent the AI from adding unnecessary complexity. I have seen AI assistants add Redux to a simple React app when I didn't ask for it. I have seen them add Docker files when I only needed code. Explicitly stating boundaries keeps the output focused.

Iterate, Don't Accept

The first answer is rarely perfect. Treat it as a draft.

"This is good, but the error handling is too generic. Make it return specific HTTP status codes."

"Refactor this to use async/await instead of promises."

"Simplify the logic. This is over-engineered."

You are the lead developer. The AI is the junior. You guide, you correct, you refine. Do not expect the first output to be copy-paste ready. Expect it to be 80% there. Your job is to push it to 100%.

When to Use It (And When Not To)

Use AI for boilerplate, repetitive tasks, and exploring new libraries. If you need to write a regex, an AI is great. If you need to refactor a 500-line legacy file, an AI is risky. It might break subtle dependencies you do not see.

Do not use AI for critical business logic without review. Do not use it for security-sensitive code without understanding every line. Do not use it to hide your lack of understanding. If you cannot explain why the code works, you are not ready to ship it.

The Takeaway

AI coding assistants are not magic. They are tools. Like any tool, they are only as good as the person using them.

Stop asking for magic. Start providing context. Stop accepting generic code. Start constraining the output. Stop treating it as a black box. Start treating it as a collaborator.

The developers who get the most value from these tools are not the ones who type the most prompts. They are the ones who think clearly about what they want, how they want it structured, and why it matters.

Your codebase is a system. The AI is a component. Integrate it properly, and it will save you hours. Integrate it poorly, and it will cost you days in debugging.

Be the architect. Let the AI be the bricklayer.

Stop Fighting Cursor: Treat It Like a Junior Dev, Not a Magic Wand

Ntty — Wed, 02 Sep 2026 11:00:19 +0000

I installed Cursor about two weeks ago with high expectations. I wanted to build a side project in a weekend. Instead, I spent the first day deleting code that the AI generated. It was confident, it was fast, and it was completely wrong.

The problem was not the tool. The problem was my prompt. I was treating the AI like an oracle. I asked it to "build a user authentication system" and expected it to know my specific stack, my database schema, and my security preferences. It did not. So it guessed. And LLMs are bad at guessing when the stakes are high.

After a few frustrating hours, I changed my approach. I stopped asking for features and started asking for functions. I treated the AI like a junior developer who is very fast but has no context about my codebase.

Context is King, Not the Prompt

The biggest mistake I see developers make is relying entirely on the chat box. Cursor has a feature that lets you index your codebase. If you are not using this, you are leaving 80% of the value on the table. But indexing is not enough. You have to be explicit about what the AI should look at.

When I started, I would just type in the chat: "Add a validation error here." The AI would guess which validation library I was using. I am using Zod. It assumed I was using Yup. The code broke.

Now, I do this differently. I open the file where I want the change. I use the @ symbol to explicitly reference the files that contain my types and my validation schemas. Then I write the prompt. The difference is night and day. When I point it at the actual source of truth, it stops hallucinating imports.

Here is a comparison of my prompts:

Bad: "Add a function to calculate tax."

Good: "Look at @types.ts and @utils.ts. Write a function in @tax.ts that calculates tax based on the Order type. Use the calculateTax logic found in the existing code. Do not install new dependencies."

The second prompt is longer. It takes more time to write. But it saves me ten minutes of debugging later. The AI has a clear boundary. It knows where to look and what rules to follow.

The Rule of Single Responsibility

I used to ask Cursor to do three things at once. "Create the component, add the API call, and update the state management." It would try to do all three in one go. Usually, it would get the API call right, but botch the state update because it did not fully understand the reducer pattern I was using.

Now, I break it down. I ask for one thing. I review it. I accept it. Then I ask for the next thing.

This sounds slower. It is not. It is actually faster because I am not trying to parse a 200-line diff that mixes three different concerns. I can review a 20-line diff in seconds. I can trust it more because the scope is small.

Think of it like code review. You do not like it when a junior dev sends you a PR that changes 50 files. You want small, focused changes. The AI is the same. Give it small tasks. It will perform better.

When to Stop Using Cursor

There are times when I close Cursor and open my normal editor. This is important. If I am doing complex refactoring or debugging a subtle race condition, the AI is a liability. It will suggest "fixes" that break other parts of the system because it does not have the full mental model of the runtime state.

Debugging is where I still rely on my own brain. I set breakpoints. I read the logs. I understand the flow. Once I understand the issue, I might ask Cursor to write the specific function that fixes it. But I do not let it diagnose the problem.

The AI is great for boilerplate. It is great for writing tests for functions I already wrote. It is great for explaining how a specific regex works. It is terrible for architectural decisions. If you let it make architectural decisions, you will end up with a Frankenstein codebase that no one can maintain.

Practical Tips for Better Results

Use the @ symbol aggressively. Reference specific files. Do not let the AI guess.
Ask for explanations, not just code. If I am not sure how a piece of code works, I ask "Explain this line by line." If the explanation does not match my mental model, I know the code is wrong.
Keep your prompts concise. Do not write paragraphs. Bullet points work best. List the constraints. List the files. List the goal.
Ignore the "magic" vibe. If it feels like it is working too well, be suspicious. Check the imports. Check the types. Run the tests.

The Takeaway

Cursor is not a replacement for your skills. It is an amplifier. If you are a weak developer, it will make you a faster weak developer. You will produce more buggy code, faster.

If you are a strong developer, it will make you a faster strong developer. You will spend less time on boilerplate and more time on the hard problems.

The key is to set boundaries. Tell the AI what to do. Tell it what not to do. Show it exactly where to look. Treat it like a tool, not a teammate.

I am not going to stop using it. It has saved me hours on my current project. But I am no longer surprised when it gets things wrong. I am just faster at correcting it. And that is the real value. Not the code it writes, but the speed at which you can iterate on your own ideas.

Go back to your editor. Open your project. Find a small task. Use the @ symbol. Ask for one specific function. See if it works. If it does, try the next one. If it does not, read the file it should have looked at. Adjust your prompt. That is how you learn to work with it.

Do not look for the magic button. There is none. There is only practice and precision.

Stop Building AI Wrappers: The Hidden Cost of 'Thin' Applications

Ntty — Tue, 01 Sep 2026 11:00:04 +0000

Last month, I spent three days building a feature for a client. The request was simple: analyze user support tickets and categorize them by urgency. I connected an LLM API, wrote a prompt that asked the model to return JSON, and the demo worked perfectly. I showed the client the results. They nodded, smiled, and said it looked great.

Then I tried to deploy it.

The first production error happened within an hour. A user submitted a ticket that contained a nested JSON string inside the text. The model got confused. It tried to parse the string as code and returned a malformed response. My backend crashed because it expected a strict schema.

I fixed the parser. Then the next issue appeared. The model started hallucinating categories that did not exist in our database. It invented a new priority level called "critical plus." I had to add logic to map unknown values to a default "low" category, but that was too aggressive. Some high-priority bugs got buried because the model was being creative.

This is the gap between a demo and a product. Most developers treat AI integration like they treat database integration. You query the database, you get data. You query the LLM, you get... vibes. The non-deterministic nature of large language models breaks standard software engineering assumptions. Here are three specific lessons I learned the hard way.

1. The Output is Not Data

When you use a traditional API, you trust the schema. If I expect an integer, I get an integer. If I expect a string, I get a string. With LLMs, the output is probabilistic. It is natural language that looks like structured data.

I stopped trying to force the model to output specific JSON. Instead, I moved the validation logic to the application layer. I now use a two-step process. First, I ask the model for a simple, unstructured summary. Second, I use a deterministic script to extract keywords and map them to my internal categories. The model provides context; the code provides structure.

If you are building anything in production, assume the model will fail. Write defensive code that handles nulls, unexpected types, and garbage input. Do not trust the prompt. Trust your validation layer.

2. Context Is Expensive and Fragile

I initially tried to feed the entire conversation history to the model for every request. It worked in testing because the conversations were short. In production, users write long, rambling emails. The context window filled up faster than I expected.

Worse, the quality of the responses degraded as the context grew. The model started repeating itself. It lost the thread of the original question. I had to implement a sliding window approach. I kept only the last five messages in the context. I also added a summary step for older messages.

But summaries introduce drift. If you summarize a conversation about a bug, and then summarize the summary, you lose details. I now store the raw data in a vector database. I retrieve only the most relevant chunks based on the current query. This reduced my token costs by 60% and improved accuracy significantly.

The lesson here is that context management is an engineering problem, not a prompt engineering problem. You need storage, retrieval logic, and cleanup jobs. You need the same infrastructure you would build for a search engine.

3. Monitoring Is Harder Than You Think

How do you know if your AI feature is breaking? In traditional apps, you monitor error rates and latency. In AI apps, you also need to monitor quality. A request can return a 200 OK status, but the answer can be completely wrong.

I built a simple feedback loop. Users can rate the response with a thumbs up or thumbs down. I log these ratings alongside the prompt and the response. Weekly, I review the negative ratings. I look for patterns. Why did the model fail? Was the prompt ambiguous? Was the data noisy?

I also added a confidence score. I ask the model to estimate its own confidence. If the confidence is below a certain threshold, I route the request to a human agent instead of showing the AI response. This reduced our support tickets by 20%, but it also gave us a safety net.

Do not launch an AI feature without a way to measure quality. You will not know if it is working until it is broken.

The Takeaway

AI is a powerful tool, but it is not a magic bullet. It does not replace your backend logic. It adds a new layer of complexity. You need robust error handling, careful context management, and rigorous monitoring.

If you are starting a new project, ask yourself: can I build this with traditional logic? If the answer is yes, do that. If the answer is no, then build the infrastructure to support the AI. Do not just wrap an API. Build a system.

The developers who succeed with AI are not the ones who write the best prompts. They are the ones who write the best code around the prompts.

Why Your Indie App Needs a Kill Switch

Ntty — Mon, 31 Aug 2026 11:00:05 +0000

I spent three years maintaining a small SaaS tool that made me about $500 a month. It was profitable. The users were happy. But I was miserable. The codebase was a mess of technical debt because I had no budget for refactoring. Every new feature took twice as long as the last. I was stuck in a loop of fixing bugs that users rarely even noticed.

The biggest mistake indie developers make is assuming that if an app works, it must always work. They build a product and treat it like a permanent home. But software is a liability, not an asset. It requires constant attention. If you are a solo developer, your time is your only real resource. You are losing it every time you push a release for a product that barely covers your server costs.

You need a kill switch. This is not about quitting in fear. It is about defining success before you start coding. What does success look like? Is it $10k MRR? Is it 1,000 active users? Is it simply learning a new technology? Define the end state. If you hit that state, you stop. If you miss it after six months, you stop. Without a deadline, you will drift. You will keep adding features to appeal to hypothetical users who never sign up.

I learned this the hard way. My app hit a plateau at month fourteen. I tried three different pricing strategies. I rewrote the backend in a language I liked better but did not know well. I spent weekends on marketing instead of code. The revenue stayed flat. The codebase got more fragile. I realized I was not building a business. I was building a job that I could not fire myself from.

When I finally killed the app, I felt a wave of relief I did not expect. I archived the repository. I sent a final email to the users explaining the shutdown. I refunded the remaining subscriptions. It took one week. The silence that followed was peaceful. I used the time I saved to start a new project with a strict three-month deadline. That project failed faster, but I learned more. I stopped wasting months on ideas that did not resonate.

A kill switch protects your mental health. It prevents the slow burn of resentment. You start to hate the code. You start to hate the users because they are the reason you are stuck. You begin to view every support ticket as an attack. A clear exit plan keeps the project fresh. You work with urgency. You make hard decisions faster because you know the clock is ticking.

How do you implement this? Do not just put it in your head. Write it down. Create a document in your repository called EXIT_CRITERIA.md. List the metrics. List the date. Share it with your community if you have one. Public accountability helps. Tell your followers that the app will sunset in December unless it hits X users. Now you have a deadline that matters. You will push harder. You will prioritize better. You will stop polishing the logo and start fixing the core bug.

Some developers resist this idea. They think it is unprofessional. They think users will lose trust. In my experience, users respect honesty more than permanence. They know apps die. They know solo developers burn out. A sudden disappearance without warning is worse than a planned sunset. A planned sunset shows confidence. It shows you are in control. It shows you value your time. Users who respect that will likely follow you to your next project.

There is also the financial angle. Keeping a low-revenue app alive often costs more than it makes. You are paying for infrastructure. You are paying for tools. You are paying for your own time. If the margin is thin, the risk is high. One server outage or a payment provider issue can wipe out a year of profit. A kill switch forces you to evaluate the true cost of ownership. You might find that you are working for free. You might find that the effort to maintain the app exceeds the value it provides.

I am not saying you should quit everything. Some indie apps become stable and require little maintenance. These are the digital gardens. They grow slowly and need little attention. But most apps are not like that. Most apps need constant feeding. If you are not ready to treat your app like a pet, do not build it. Build projects with clear goals. Build tools that solve a specific problem and then retire them.

Start the next project with a timer. Set it for ninety days. If it is not working, stop. If it is working, extend it by another ninety days. This keeps the momentum going without trapping you. It keeps the codebase small. It keeps your skills sharp. It keeps your sanity intact.

The indie space is full of graveyard projects. Abandoned repositories. Broken links. Forgotten domains. Do not add to the pile. Build, test, and release. Then decide if it is worth keeping. Most of the time, the answer is no. And that is okay. Moving on is not failure. Staying stuck is.

Take your time. You do not need to build forever. You just need to build well, and then let go.

Stop building features and start finding your first 10 paying users

Ntty — Fri, 28 Aug 2026 11:00:03 +0000

The Build Trap

I spent six months building a project a few years ago that I thought was a masterpiece. I had a clean architecture, 90% test coverage, and a CI/CD pipeline that would make a Fortune 500 company proud. When I finally launched it on Product Hunt and Hacker News, I got a few hundred upvotes, some 'nice project' comments, and exactly zero dollars.

I fell into the build trap. As developers, we feel safe in the IDE. Writing code feels like progress. But in the world of indie hacking, writing code before you have a validated problem is actually a form of procrastination. It is a way to avoid the scary part: asking people to pay you.

The 'Pain' Threshold

Most dev tools fail because they solve a 'mild annoyance' rather than a 'burning pain'.

A mild annoyance is something like, "I wish my logs were a bit more colorful." People will star your GitHub repo for that, but they will not pull out a credit card for it.

A burning pain is, "I am losing $500 an hour because I cannot debug this production crash." That is where the money is.

To find this, you need to stop looking at your code and start looking at where people complain. Search Twitter, Reddit, and Stack Overflow for phrases like "How do I...", "Why is it so hard to...", or "I hate it when [tool] does [x]."

The Manual Validation Phase

Before you write a single line of production code, try to solve the problem manually. If you are building a tool that automates a workflow, do the workflow yourself for three different users via email or Zoom.

If you cannot find three people who are willing to let you solve their problem manually, they definitely will not pay for a software subscription to do it. This phase is brutal because it is not scalable, but that is the point. Scaling a product that nobody wants is the fastest way to burn out.

Pricing as a Feature

One of the biggest mistakes I see indie devs make is the "Free for now" strategy. They launch a beta for free, get 1,000 users, and then try to introduce a pricing plan six months later.

What happens? The users leave.

Why? Because you attracted "free users," not "paying customers." These are two entirely different demographics. A paying customer is someone who values their time more than their money. A free user often values their time less than the effort it takes to set up a new tool.

Put a pricing page up on day one. Even if the "Buy" button just leads to a waitlist or a "Coming Soon" page, you need to see if people are willing to click it. That click is the only metric that actually matters.

The Minimum Viable Product (MVP) is too big

Your MVP should probably be smaller than you think. If you think your MVP needs a dashboard, a user profile page, and an API key management system, you are building a product, not an MVP.

Ask yourself: what is the one single action that provides the value?

If your tool optimizes AI wait-states, the value is the reduced friction during the load time. You do not need a complex billing portal or a fancy landing page to test that. You need a functional script and a user who cares about that specific lag.

Concrete Takeaway

Stop polishing your codebase. If you have spent more time on your folder structure than you have talking to potential users, you are in the danger zone.

Set a rule for yourself: for every hour of coding, spend one hour on distribution or user research. Send the cold DMs. Post the awkward threads on Reddit. Get rejected. It is better to find out your idea is bad in week two than in month six.

If you are looking for a way to make your own AI tools feel more responsive while you build, check out https://waitspin.com to handle those loading states. Now, go close your IDE and find a customer.

Stop Over-Engineering Your State Management

Ntty — Wed, 26 Aug 2026 11:00:03 +0000

The 'Store' Trap

I spent three years of my career thinking that every single piece of data in a web app belonged in a global store. Whether it was a user profile, a theme toggle, or a simple 'is loading' boolean for a single button, it all went into Redux or Vuex.

I thought this was 'professional' architecture. In reality, I was just creating a massive, tangled web of boilerplate that made the codebase impossible to navigate.

When you put everything in a global store, you lose the ability to reason about your components in isolation. You start treating your frontend like a database rather than a UI.

The Hierarchy of State

To keep a project maintainable, you need to be strict about where state lives. I now follow a simple hierarchy of needs.

1. Local Component State

If the data is only used by one component, keep it there. This includes form inputs, toggle switches, and hover states.

One common mistake is lifting state up too early. Developers often move state to a parent component because they think it might be needed elsewhere later. This creates 'prop drilling', where you pass data through five layers of components that do not even use it. Resist this. Keep state as low as possible.

2. Composition and Slots

Before reaching for a global store to solve prop drilling, try component composition. Instead of passing data down, pass the component itself as a child.

By passing a pre-configured component into a wrapper, you remove the need for the middleman components to know about the data. This keeps your components decoupled and makes them much easier to test.

3. Context or Provide/Inject

Context is for data that is truly global but rarely changes. Think of the current user's authentication status, the app locale, or a theme.

Context is not a replacement for a state management library. The biggest issue with Context is that it triggers a re-render of all consumers whenever any value in the provider changes. If you put high-frequency updates (like a timer or a text input) in Context, your app will lag.

4. Dedicated State Stores

Use a store (like Zustand, Pinia, or Redux) only when you have complex data that is shared across distant parts of the application and updates frequently.

Examples include a shopping cart, a complex dashboard with multiple synced widgets, or a real-time chat system. If you cannot explain why the data needs to be global in one sentence, it probably does not belong in a store.

Dealing with Server State

Here is the biggest realization I had: most of what we call 'state' is actually just a cache of data from the server.

Fetching a list of users and putting it in a global store is often a waste of time. You have to manually manage loading states, error states, and cache invalidation.

Instead, use a dedicated server-state library. These tools handle caching, re-fetching on window focus, and loading states automatically. This removes about 50 percent of the code in most global stores because you no longer need to track 'isLoading' or 'isError' for every single API call.

Concrete Takeaway

Next time you are about to add a new piece of state, ask yourself these three questions in order:

Can this live inside a single component?
Can I solve this by changing how I nest my components (composition)?
Is this actually server data that just needs to be cached?

If the answer to all three is 'no', only then should you reach for a global store. Your future self, and anyone else who has to read your code, will thank you for the simplicity.

Stop Letting Your AI Editor Write Your Logic

Ntty — Tue, 25 Aug 2026 11:00:35 +0000

I recently spent a month using Cursor for a production project. The speed is intoxicating. You hit Cmd+K, describe a feature, and suddenly 50 lines of TypeScript appear. It feels like you have a junior developer who never sleeps and types 1000 words per minute.

But after a few weeks, I noticed a dangerous pattern. I was spending more time reviewing AI diffs than actually designing the system. I found myself accepting suggestions that worked on the surface but introduced subtle technical debt and inconsistent naming conventions. I was no longer the architect. I was a glorified proofreader.

If you want to stay a strong engineer while using these tools, you need a strategy to prevent cognitive atrophy.

The Trap of the Auto-Complete Loop

When an AI editor suggests a block of code, your brain naturally wants to take the path of least resistance. If the code runs and the tests pass, you hit 'Accept'.

This is where the problem starts. You stop thinking about the edge cases because the AI provided a solution that looks complete. You stop considering if a different design pattern would be more scalable because the current one is already written. You are essentially outsourcing your decision-making process to a probabilistic model.

How to Maintain Control

To avoid this, I implemented three strict rules for my workflow.

1. Pseudo-code First

Never start with a prompt. Instead, write a comment block explaining the logic in plain English.

Example:
// 1. Fetch user data from API
// 2. Validate if the user has admin permissions
// 3. Map the raw API response to our internal User interface
// 4. Handle the 404 case specifically for missing profiles

Once the logic is mapped out, then you use the AI to fill in the boilerplate. This ensures that the architectural decisions are yours, not the model's.

2. The 'Why' Audit

Every time you accept a significant block of AI code, ask yourself: Why did it choose this approach? If the AI used a .reduce() where a .map() would be clearer, change it. If it introduced a new dependency you didn't ask for, strip it out.

If you cannot explain exactly why the AI wrote a specific line, you should not commit it. This forces you to actually read the code instead of just skimming the diff.

3. Manual Refactoring Sprints

Every few days, I take a module written primarily by AI and refactor it manually. I look for repetitions, awkward abstractions, or missing error handling that the AI glossed over. This keeps your critical thinking muscles active and ensures the codebase remains cohesive.

Dealing with Hallucinated APIs

One of the biggest frustrations with AI editors is when they invent methods that do not exist in your library. It happens often with newer versions of frameworks.

When this happens, do not just prompt it to fix it. Stop. Go to the official documentation. Read the actual API spec. Then, feed that specific snippet of documentation back into the AI context. This turns the tool from a guessing machine into a precision instrument.

The Concrete Takeaway

AI editors are incredible for eliminating boilerplate and speeding up repetitive tasks. They are terrible at long-term architectural integrity.

Your value as a developer is not your ability to generate lines of code. It is your ability to make decisions about which lines of code should exist. Use the tool to handle the syntax, but never let it handle the strategy. If you stop thinking, you stop growing.

Vibecoding: Why Flow State is the New Syntax

Ntty — Mon, 24 Aug 2026 11:00:39 +0000

The Shift in the Mental Model

For a decade, coding was about the syntax. We spent hours debugging a missing semicolon or fighting with a TypeScript generic that refused to resolve. The value was in knowing the specific API calls and the exact way to structure a loop for performance.

Now, we are entering an era of "vibecoding." This is not about being lazy. It is about shifting the developer's role from a writer of lines to an architect of intent. When you use LLMs to generate large chunks of logic, you are no longer focused on the how, but the what. You are coding by vibe, describing the desired behavior and iterating until the result feels right.

The Danger of the Black Box

There is a trap here. When you vibe-code, it is easy to enter a state of passive acceptance. You prompt, the AI generates 50 lines of code, it looks correct, and it passes the basic test. You move on.

This is where the technical debt starts. If you do not understand the underlying implementation, you are not building a system, you are stacking magic spells. The moment a bug appears in that generated block, you will spend three times longer fixing it because you did not actually author the logic. You only approved the vibe.

How to Vibe-Code Responsibly

To make this work without ruining your project, you need a new workflow. You cannot just prompt and pray.

First, use a "Review-First" mindset. Treat the AI as a junior developer who is incredibly fast but occasionally hallucinates. Every block of code generated must be audited. If you cannot explain what a specific line does, do not commit it.

Second, lean heavily on TDD (Test Driven Development). When you are coding by intent, the tests are your only guardrails. Write the test first to define the "vibe" you want. If the AI generates code that passes the test but looks messy, tell it to refactor for readability. The test ensures correctness, while you ensure maintainability.

Third, maintain a strict style guide. AI can drift in style. One prompt might give you functional patterns, the next might give you class-based OOP. You have to be the one enforcing consistency across the files, or your codebase will look like a patchwork quilt of different eras of programming.

The New Skill: Intent Engineering

The real skill is no longer memorizing the documentation for a library. It is the ability to decompose a complex problem into a series of clear, unambiguous intents.

If you ask for a "user authentication system," you will get a generic, potentially insecure mess. If you ask for a "JWT-based auth flow with refresh tokens stored in http-only cookies and a specific password hashing salt," you are directing the vibe.

Precision in language is the new precision in syntax. The better you can describe the edge cases, the better the output. You are essentially writing a specification in real-time.

The Bottom Line

Coding is becoming less about the mechanical act of typing and more about the cognitive act of reviewing and directing. This is an exciting shift, but it requires more discipline, not less.

If you stop caring about how the code works because the "vibe" is correct, you are no longer an engineer. You are a prompt operator. The best developers in this new era will be those who can move fast with AI tools but still possess the deep knowledge to tear that code apart when it fails.

Takeaway: Use AI to handle the boilerplate and the initial drafting, but never outsource the architectural review. Your job is to be the filter, not just the conduit.

Stop building the 'Perfect' SaaS and start charging for it

Ntty — Sun, 23 Aug 2026 11:00:55 +0000

The Trap of the 'One More Feature'

I spent six months building a project a few years ago that never saw a single user. I had a fully automated CI/CD pipeline, a perfectly normalized database schema, and a custom-built authentication system because I didn't trust the third-party options. I felt like I was making progress because I was writing code every day.

Here is the truth: writing code is not the same as building a business. For most developers, coding is the comfortable part. Marketing, pricing, and talking to strangers are the scary parts. So, we hide in the IDE. We tell ourselves that the product is not ready yet. We think, 'If I just add this one more feature, people will actually pay for it.'

This is a lie. Most of the features you think are essential are actually noise. Your users do not care about your clean architecture or your test coverage. They care about whether your tool solves a specific, painful problem in their day.

The MVP is usually too big

Most developers define a Minimum Viable Product (MVP) as a fully functional version of their final vision. That is not an MVP. An MVP should be the smallest possible thing that provides value.

If you are building a tool to automate reports, you do not need a fancy dashboard with drag-and-drop widgets. You need a script that takes a CSV and emails a PDF. If someone is not willing to pay for the ugly, manual version of your solution, they certainly will not pay for the polished version.

I learned this the hard way. I once spent three weeks building a complex onboarding flow with tooltips and progress bars. When I finally launched, I found out that the users did not even want the main feature of the app. I wasted three weeks polishing a door to a room nobody wanted to enter.

How to actually validate

Validation is not asking your friends if they like your idea. Your friends will lie to you because they like you. Real validation is a transaction.

Here are three ways to validate without spending months on code:

The Manual Bridge: Do the work by hand. If your SaaS is supposed to automate a task, do that task manually for a client. If they pay you for the manual result, you have a business. Now you can write code to automate what you just did.
The Pre-Sale: Create a landing page that describes the value. Put a 'Buy Now' button that leads to a waitlist or a pre-order form. If people click that button, you have a signal.
The concierge approach: Work with one single user. Build exactly what they need, deploy it, and watch them use it. Ignore everyone else until that one person is getting value.

Pricing as a feature

Many devs are terrified of pricing. We want to offer a generous free tier because we want 'growth'. But free users are often the most demanding and the least likely to help you build a sustainable product.

Charging money is a filter. It separates the people who have a real problem from the people who are just curious. When someone pays you, they are giving you a mandate to fix their problem.

Do not start with a complex pricing table. Start with one flat fee. It removes the friction of decision-making for the user and the friction of bookkeeping for you.

The Takeaway

Build the smallest possible version of your idea. Launch it while you are still slightly embarrassed by how simple it is. If it fails, you lost two weeks instead of six months. If it succeeds, you have a roadmap written by your customers, not your assumptions.

Focus on the value, not the stack. If you find yourself spending more time on your build pipeline than on your landing page, you are procrastinating via engineering.

For those building tools that involve waiting for AI responses or long processes, keep the UX simple. A clear indicator like the one at https://waitspin.com is often all you need to keep a user from refreshing the page while your backend works.

Stop Treating AI Editors Like Magic Wands

Ntty — Sat, 22 Aug 2026 11:00:58 +0000

The Honeymoon Phase

I spent the first two weeks with Cursor thinking I had found a cheat code. I was hitting Cmd-K, typing a vague request, and watching the code rewrite itself. It felt like I was managing a junior developer who worked at light speed.

Then the bugs started appearing. Not the obvious syntax errors, but the logic gaps. The AI would change a variable type in one file and forget to update the interface in another. Because I was skimming the diffs instead of reading them, I started shipping regressions that I would have caught in five seconds using a traditional editor.

The Trap of the Diff-Review

When you use an AI editor, the primary activity shifts from writing code to reviewing diffs. This is a dangerous shift if you are not careful.

Reviewing a diff is cognitively different from writing the logic. When you write code, you are building a mental model of the data flow. When you review a diff, you are often just checking if the code looks right. This is where the "hallucination creep" happens. The AI suggests a change that looks elegant, fits the pattern of the project, and passes the initial test, but misses an edge case that only happens in production.

A Better Workflow

To stay in control, I had to change how I interact with the tool. Here is the system I use now to ensure I actually understand what is being added to my repo.

1. The Pseudo-Code Prompt

Instead of asking the AI to "implement the payment logic," I now prompt it with the logic steps I want.

Example: "Create a function that takes the cart object, validates the stock levels via the API, calculates the tax based on the user's state, and returns a final total. Use the existing TaxCalculator class."

By defining the steps, I am still the architect. I am not delegating the thinking, just the typing.

2. Small Atomic Changes

It is tempting to highlight 100 lines of code and ask for a refactor. Do not do this. The larger the change, the more likely the AI is to omit a crucial line of logic or introduce a subtle bug.

I now limit my AI edits to small, atomic chunks. If a feature requires five changes, I do five separate prompts. This makes the diffs manageable and the reverts easy.

3. The "Explain it Back" Rule

Whenever the AI suggests a complex block of logic that I did not explicitly dictate, I ask it to explain why it chose that specific approach. If the explanation sounds generic or doesn't make sense, I delete the code and write it myself. If you cannot explain why a piece of code is there, it does not belong in your codebase.

The Danger of Context Overload

AI editors have access to your entire folder. While this is great for finding where a function is defined, it can lead to "context pollution."

Sometimes the AI sees a deprecated pattern in an old file and decides to replicate that pattern in your new feature because it thinks that is the project style. I have found that manually adding only the relevant files to the context window is far more effective than relying on the automatic index. It forces you to think about the dependencies of the feature you are building.

The Takeaway

AI editors are tools for acceleration, not replacement. The goal is to reduce the friction of boilerplate and repetitive patterns, not to stop thinking about how the software works.

If you spend more time clicking "Accept" than you do reading the actual lines of code, you are creating a technical debt bomb that will explode the first time you have to debug a production outage at 3 AM. Keep the architect in the driver's seat and use the AI as a high-speed typist.