DEV Community: Ntty

Stop Letting AI Write Your Entire Component

Ntty — Mon, 13 Jul 2026 11:00:07 +0000

I spent the last three months using an AI-first editor. At first, it felt like a superpower. I could hit a keyboard shortcut, describe a feature, and watch 50 lines of React code appear. It felt fast. Then, the bugs started hitting.

I realized I had developed a dangerous habit: I was accepting code I did not fully understand. When a production bug appeared in a component written by the AI, I spent forty minutes trying to figure out the logic because I had not actually written it. I was the reviewer of my own code, but I was a lazy reviewer.

Here is how I changed my workflow to actually stay in control.

The Trap of the Big Prompt

The biggest mistake is asking for a whole feature in one go. If you prompt "Build me a paginated table with sorting and filtering," the AI will give you a massive block of code. It will look correct. It will probably work on the first run.

But that code is a black box. It often includes unnecessary dependencies, weird edge-case handling that doesn't fit your project, or outdated API patterns. When you accept a 100-line diff, you are essentially signing a contract to maintain 100 lines of logic you did not architect.

The Atomic Prompting Method

Instead of big blocks, I moved to atomic prompts. I break the task down into the smallest possible logical units.

First, I define the types or the interface. I prompt for the TypeScript definition only. I review it. I tweak it. Once the data shape is locked in, I move to the next step.

Next, I prompt for a single helper function. For example, "Write a function to sort this specific array of objects by date." I test that function in isolation.

Finally, I ask the AI to wire these pieces into the UI. By the time the component is finished, I already understand every helper function and every type definition because I guided the process step by step.

Using the AI as a Rubber Duck, Not a Ghostwriter

I started using the chat feature differently. Instead of saying "Fix this bug," I now say "Explain why this bug might be happening and give me three possible directions to investigate."

This forces my brain to stay engaged. If the AI just gives me the fix, my brain switches off. If the AI gives me the theory, I still have to do the work of implementing the solution. This is where the actual learning happens. If you stop solving problems, your skills will atrophy. You become a prompt engineer, which is a fancy way of saying you are a middleman between a requirement and a machine.

The Code Review Rule

I implemented a personal rule: I cannot commit any AI-generated code until I can explain every single line to a hypothetical junior developer.

If there is a regex pattern the AI generated that looks like magic, I do not accept it. I ask the AI to break down the regex. I test it against a few strings. Once I understand the magic, I commit it.

This slows down the initial development speed, but it drastically reduces the time spent in the debugging phase. Speed is a lie if it leads to technical debt that you cannot navigate.

Concrete Takeaways

If you are using an AI editor, try these three things this week:

Limit your diffs. If an AI suggests more than 20 lines of change at once, break your prompt into smaller pieces.
Prompt for the "Why" before the "How". Ask for the logic or the plan before you ask for the code.
Manual Refactor. After the AI generates a working solution, manually rename variables or restructure a loop to fit your style. This forces you to read the code carefully.

AI is a great tool for removing boilerplate, but it is a terrible architect. Keep the architecture in your head, and use the AI to fill in the gaps.

Stop Prompting and Start Engineering: Treating LLMs as Unreliable Functions

Ntty — Sun, 12 Jul 2026 11:00:48 +0000

Most developers start with AI by writing a long prompt and hoping the model returns a valid JSON object. This works 80 percent of the time. In production, that 20 percent failure rate is a disaster. It leads to runtime errors, broken UI components, and endless debugging sessions where you try to "tweak the wording" of a prompt to fix a bug.

I spent three months building a feature that relied on an LLM to categorize user feedback. Every time I updated the prompt to fix one edge case, it broke two other things. I realized I was treating the AI as a magic box rather than a software component.

Here is how to move from guessing to engineering.

The Fallacy of the Perfect Prompt

Prompt engineering is often sold as a way to get the perfect answer. But LLMs are probabilistic, not deterministic. Even with the temperature set to zero, you cannot guarantee a consistent output format across different model versions or high-load periods.

If your code assumes the AI will always return a specific key in a JSON object, your code is fragile. You are essentially calling a function that might change its return type at any moment without warning.

Implementing the Wrapper Pattern

Instead of trusting the output, build a validation layer between the LLM and your business logic. Treat the LLM output as "untrusted user input."

First, define a strict schema for what you expect. Use a library like Zod or Pydantic to validate the response immediately after it arrives. If the validation fails, do not let the data reach your database or your frontend.

Second, implement a retry loop with a fallback. If the LLM returns a malformed response, send the error message back to the LLM and ask it to fix the specific formatting error. This is far more effective than just retrying the same prompt three times.

Constraining the Output Space

One of the biggest mistakes is asking the AI to "describe" something. Descriptions are variable. Instead, force the AI to choose from a predefined list of enums.

Instead of:
"Categorize this feedback as positive, negative, or neutral."

Try:
"Categorize this feedback. You must choose exactly one value from this list: [POSITIVE, NEGATIVE, NEUTRAL]. Do not include any other text in your response."

By limiting the output space, you make the validation layer simpler and the results more predictable.

Testing for Regressions

How do you know if a prompt change actually improved the system? You cannot rely on a few manual tests. You need a golden dataset.

Create a JSON file containing 50 to 100 examples of inputs and the expected outputs. Every time you change a prompt, run your entire dataset through the model. If you fix the "edge case" but change five other correct answers to incorrect ones, your prompt is a regression.

This turns prompt engineering into a measurable process. You are no longer guessing if it feels "better." You have a percentage accuracy score.

Concrete Takeaway

Stop trying to write the perfect prompt. It does not exist. Instead, build a system that expects the AI to fail.

Validate every response against a strict schema.
Use enums to limit the output range.
Build a test suite of inputs and expected outputs to track regressions.

When you treat the LLM as an unreliable function, you can build reliable software around it.

Stop Treating LLM Prompts Like Magic Spells

Ntty — Sat, 11 Jul 2026 11:00:48 +0000

I spent the first few months of the AI boom treating prompts like magic spells. I would tweak a word here, add 'think step by step' there, and hope for the best. When it worked, I felt like a wizard. When it broke in production, I had no idea why.

If you are building features that rely on Large Language Models (LLMs), you need to stop guessing. Prompting is not a mystical art. It is a configuration problem.

The Problem With 'Vibe-Based' Development

Most developers start with a single long string in a variable. They send it to the API, look at the output, and manually edit the string until the output looks right. This is vibe-based development.

The issue is that LLMs are non-deterministic. A prompt that works for one edge case might fail for another. If your prompt is a 500-word block of text, changing one sentence to fix a bug in the 'user profile' logic might accidentally break the 'password reset' logic.

Moving Toward a Systematic Approach

To build reliable software, you need to treat your prompts like code. Here is the framework I use now.

1. Separate Instructions from Data

Stop concatenating strings. Use clear delimiters. If you are passing a user's document for analysis, do not just slap it at the end of the prompt. Wrap it in XML-style tags or clear markers.

Instead of:
"Summarize this text: [text]"

Use:
"Summarize the content found between the tags.

[text]
"

This prevents prompt injection and helps the model distinguish between your instructions and the data it is processing.

2. Implement Few-Shot Prompting

Asking a model to "be professional" is useless. Professional means different things to different people. Instead, give it three to five examples of exactly what you want.

Provide a pattern:
Input: [Example 1]
Output: [Example 1 Result]

Input: [Example 2]

By providing concrete examples, you reduce the variance in the output. You are essentially giving the model a template to follow rather than asking it to imagine a style from scratch.

3. Enforce Structured Output

Parsing raw text with regex is a nightmare. If you need data to flow into a database or a UI, force the model to return JSON.

Do not just ask for JSON. Define the schema. Tell the model: "Return a JSON object with the keys 'status' (string), 'id' (integer), and 'summary' (string). Do not include any conversational filler or markdown formatting."

Most modern APIs have a 'JSON mode' or 'Tool calling' feature. Use them. They move the validation from the prompt level to the API level, which is much more stable.

The Importance of a Golden Dataset

This is the part most people skip. You cannot improve what you cannot measure.

Create a 'Golden Dataset'. This is a simple JSON file containing 20 to 50 pairs of inputs and the ideal expected outputs. Every time you change a prompt, run your entire dataset through the model.

If you fix a bug for case #4 but break case #12, you will know immediately. You can use a second LLM to grade the results or do manual spot checks. This turns your prompt engineering into a regression test suite.

Concrete Takeaway

Stop treating your prompt as a single string. Treat it as a versioned asset. Separate your instructions from your data using tags, provide 3-5 concrete examples, and validate every change against a fixed set of test cases.

When you move from 'I think this works' to 'I know this works for these 50 cases', your AI features actually become production-ready.

Why Your SaaS Database Schema Will Break at 10k Users

Ntty — Fri, 10 Jul 2026 11:00:49 +0000

I spent two years building a SaaS product where I thought I was being clever with my database design. I used a single shared table for everything and just slapped a tenant_id column on every single row. It worked great during the beta. It worked great for the first 500 users. Then we hit a growth spurt, and the system started crawling.

If you are building a multi-tenant app, you probably started with the same pattern. It is the easiest way to get to market. But there are specific walls you will hit that no amount of "upgrading the server" will fix.

The Indexing Trap

When you have a tenant_id on every table, your instinct is to create a composite index on (tenant_id, id) or (tenant_id, created_at). For a while, this is fast. But as your table grows to millions of rows, those indexes become massive.

One specific problem I ran into was index fragmentation. Because data for different tenants is interleaved in the same physical storage, the database spends more time jumping around the disk than actually reading data. You end up with high IOPS and slow queries even when the result set is small.

The Danger of 'The Big Table'

In a SaaS, you usually have one or two tables that grow 100x faster than others. For me, it was the audit_logs table.

Because every single action by every single user in every single tenant went into one table, the index for that table eventually exceeded the available RAM. Once the index no longer fits in memory, every single query triggers a disk read. Your API response times go from 50ms to 2 seconds overnight.

If you are seeing this, stop trying to optimize the query. You need to partition your data. Whether you use PostgreSQL partitioning or move those logs to a different storage engine, you cannot keep a trillion rows of audit logs in a single flat table.

The 'Noisy Neighbor' Problem

This is the part they do not tell you in tutorials. In a shared schema, one huge client can kill the experience for everyone else.

I had one customer who uploaded 50,000 records via a CSV import. Their queries started scanning huge chunks of the index. Because the database was working so hard to serve that one tenant, the CPU spiked to 100 percent. Suddenly, the 50 small customers who only had 10 records each were seeing timeouts.

When you share a database, you share the resources. If you do not implement rate limiting at the application level or use database-level resource quotas, your biggest customer will accidentally become your biggest liability.

How to Fix It Before It Breaks

If you are still early, you do not need to move to a "database per tenant" model. That adds massive overhead for migrations and backups. Instead, try these three things:

Strict Query Scoping: Wrap your database calls in a way that makes it impossible to forget the tenant_id filter. If you forget it once, you have a massive security leak where one user sees another user's data.
Early Partitioning: If you have a table that grows linearly with usage (like logs or events), partition it by time or by tenant ID from day one. It is much easier to start with partitions than to migrate a 500GB table later.
Read Replicas for Analytics: Never let your users run "Export all data to CSV" queries on your primary write database. Route those heavy, scanning queries to a read replica. This prevents a single heavy report from locking tables and freezing the app for everyone.

The Concrete Takeaway

Do not assume a shared schema scales linearly. The moment your indexes stop fitting in RAM, your performance will fall off a cliff. Monitor your buffer cache hit ratio and identify your fastest-growing tables now. If a table is growing by millions of rows a month, plan your partitioning strategy today, not when the site goes down.

Stop Building Chatbots and Start Building Agentic Workflows

Ntty — Thu, 09 Jul 2026 11:00:56 +0000

The Trap of the Single Prompt

Most developers start their AI journey by building a 'wrapper'. You take a user input, wrap it in a system prompt, send it to an LLM, and return the result. If the result is wrong, you try to 'prompt engineer' your way out of it by adding more instructions to that single prompt.

This is a dead end. No matter how good your prompt is, LLMs struggle with complex tasks in a single pass. They hallucinate, they skip steps, and they fail to double check their own work.

Agentic workflows are different. Instead of one long prompt, you break the task into a loop of smaller, specialized steps where the LLM can reason, act, and correct itself.

From Linear to Iterative

In a standard chatbot, the flow is: User -> Prompt -> LLM -> Output.

In an agentic workflow, the flow looks more like: User -> Planner -> Executor -> Critic -> Refiner -> Output.

Think of it like a professional software project. You do not just write 1,000 lines of code in one go and push to production. You write a draft, you run tests, you find bugs, and you fix them. That is exactly how you should structure your LLM calls.

Three Patterns That Actually Work

1. The Reflection Pattern

This is the simplest agentic move. You ask the LLM to generate a response, and then you send that response back to the LLM (or a different model) with a prompt like: "Review the response above for technical errors or missing requirements. List the flaws."

Once you have the critique, you send both the original response and the critique back to the model to generate a final version. This almost always produces a higher quality result than a single prompt, especially for coding tasks.

2. Tool-Use Loops (ReAct)

Instead of hoping the LLM knows the answer, give it tools. A tool is just a function the LLM can choose to call.

The pattern works like this:

The model thinks about what it needs (Thought).
It decides which tool to call (Action).
Your code executes that tool and feeds the result back to the model (Observation).
The model repeats this until it has enough information to answer.

This prevents the model from guessing. If it needs a current stock price or a specific database record, it fetches it rather than hallucinating a plausible-looking number.

3. Multi-Agent Delegation

When a task is too large, a single agent gets confused. The context window gets cluttered with irrelevant details. The solution is to split the roles.

Create a 'Manager' agent that breaks the goal into sub-tasks. Then, assign those tasks to 'Worker' agents. For example, one agent handles API documentation, another handles implementation, and a third handles testing. The Manager collects the outputs and ensures they align.

The Hard Part: State Management

Moving to agentic workflows introduces a new problem: state. You are no longer managing a single request, but a conversation history that includes thoughts, tool outputs, and critiques.

If you do not manage this carefully, your token costs will explode, or the model will lose the original goal. I recommend using a structured state object (like a JSON store) rather than just appending everything to a chat history string. Keep track of:

The original goal
The current step in the plan
The history of tool calls
The latest critique

Concrete Takeaway

Stop trying to write the 'perfect prompt'. It does not exist.

If your LLM is failing at a task, do not add more adjectives to the prompt. Instead, split the task into two steps: one to generate a draft and one to critique it. Then, feed that critique back in for a second pass.

Moving from a linear pipeline to an iterative loop is the single biggest jump in quality you can make in AI development.

Stop treating LLMs like databases

Ntty — Wed, 08 Jul 2026 11:00:21 +0000

I spent three months building a feature where an LLM handled our internal documentation queries. I fed it a massive system prompt containing our API specs and a few dozen examples. For the first week, it felt like magic. Then, we updated one endpoint in our API, and the bot started hallucinating old parameters and confidentially lying to our users.

That was the moment I realized I was treating the LLM like a database. It is not a database. It is a reasoning engine.

The Knowledge Cutoff Trap

When you put data inside a prompt, you are using the model's context window as temporary RAM. This is expensive and fragile. The biggest issue is that LLMs are probabilistic, not deterministic. If you ask a SQL database for a user's email, you get the exact string stored in that row. If you ask an LLM for a detail buried in a 5,000 word prompt, it might get it right 95% of the time, but that 5% failure rate is where the bugs live.

I noticed that as my system prompt grew, the model started ignoring instructions in the middle. This is a known phenomenon called the "lost in the middle" effect. The more data you cram into the prompt to make it "smarter," the more you degrade its ability to follow specific logic.

Moving to RAG (Retrieval Augmented Generation)

To fix this, I shifted to a RAG architecture. Instead of giving the model all the data upfront, I built a pipeline that retrieves only the relevant snippets of information based on the user's query.

Here is the mental shift:

Database: Stores the facts.
Retrieval Step: Finds the specific facts needed for the current question.
LLM: Rewrites those facts into a human-sounding answer.

By separating the knowledge from the reasoning, I solved two major problems. First, updating information became instant. I just update a document in the vector store, and the LLM sees the new version immediately. No need to re-engineer the prompt or wait for a fine-tuning run.

Second, I gained auditability. When the bot gives an answer, I can log exactly which document snippet was retrieved. If the answer is wrong, I know if it is because the retrieval failed (wrong data) or the LLM failed (wrong reasoning).

The Danger of Over-Prompting

Many developers try to solve logic errors by adding more "rules" to the prompt. "Always do X, never do Y, remember to Z." This creates a fragile house of cards. Eventually, two rules will conflict, and the model will pick one at random.

If you find your prompt is becoming a 200 line list of constraints, you probably need a state machine or a piece of traditional code. I replaced a complex "if-then" prompt chain with a simple Python switch statement that routed queries to different specialized prompts. The reliability jumped immediately.

Practical Takeaways

If you are building AI features, follow these rules to keep your sanity:

Keep your system prompts lean. Focus on the persona and the output format, not the raw data.
Use a vector database for any information that changes more than once a month.
If a task requires strict logic, write a function in your language of choice and let the LLM call that function instead of trying to "convince" the LLM to be logical.
Log the retrieved context. You cannot debug an LLM if you do not know what data it was looking at when it hallucinated.

Stop trying to make the model remember everything. Let it be the brain, and give it a library to look things up in.

Stop Over-Engineering Your First Indie Project

Ntty — Tue, 07 Jul 2026 11:00:45 +0000

I spent three weeks picking a database for a project that ended up getting four users. All of them were my cousins.

As developers, we are trained to build for scale. We think about concurrency, latency, and maintainability from day one. But when you are building an indie project, your biggest risk is not a server crash. Your biggest risk is building something that nobody wants to use.

The Infrastructure Trap

It is easy to hide from the scary part of shipping by focusing on the technical stack. Spending five days configuring a Kubernetes cluster or debating between PostgreSQL and MongoDB feels like work. It feels productive because you are writing code and reading documentation.

In reality, this is often a form of procrastination. You are optimizing for a problem you do not have. If your app gets 10,000 users in a day, you will have a great problem. Until then, the most scalable piece of software is the one that is actually live.

The Boring Stack Advantage

When I started shipping smaller projects, I switched to what I call the Boring Stack. This means using tools I already know inside and out, even if they are not the trendiest options on GitHub right now.

If you know Rails, use Rails. If you know Laravel, use Laravel. If you know basic Node and Express, stick with that.

Every hour you spend learning a new framework for a side project is an hour you are not spending on the actual product. The goal of an indie project is to validate an idea. You do not need a distributed system to validate if people want a specialized calorie tracker for dogs.

Where to Actually Focus

Instead of worrying about the backend architecture, focus on these three areas:

The Core Loop: What is the one thing the user comes to do? Make that path as short as possible. If it takes ten clicks to reach the value, they will leave.
Data Integrity: You do not need a complex NoSQL schema, but you do need to make sure you are not losing user data. Simple relational databases are almost always the right choice here.
The Feedback Loop: Build a way to talk to your users. A simple email link or a basic contact form is more valuable than a perfectly tuned API.

Dealing with the Fear of Refactoring

One common argument for over-engineering is the fear of technical debt. You tell yourself, "If I do it the right way now, I won't have to rewrite it later."

Here is the truth: you probably will have to rewrite it. But you will rewrite it based on how users actually use the tool, not based on how you imagined they would use it.

Writing "throwaway code" is a skill. Write the simplest version that works. If the project fails, you wasted very little time. If it succeeds, you now have the revenue or the user base to justify the time it takes to refactor the messy parts.

The Concrete Takeaway

Next time you start a project, set a strict limit on your setup phase. Give yourself 48 hours to pick your stack and deploy a "Hello World" to a live URL. If you spend more time than that on configuration before you have a single functional feature, you are over-engineering.

Ship the ugly version. Fix the database later. The only metric that matters in the beginning is whether or not a stranger finds your tool useful.

SEO for Developers: Beyond Meta Tags

Ntty — Mon, 06 Jul 2026 11:00:31 +0000

Most developers treat SEO as a checklist of meta tags that the marketing team asks for. We add a title, a description, and maybe some Open Graph tags, then we assume the job is done. But modern SEO is less about keywords and more about engineering performance and accessibility.

If you want your site to rank, you need to stop thinking like a writer and start thinking like a browser.

The Performance Trap

Google uses Core Web Vitals as a ranking signal. This means your choice of framework and how you load assets directly affects your position in search results. The biggest culprit is usually Cumulative Layout Shift (CLS).

CLS happens when elements jump around while the page is loading. This often occurs because images do not have defined dimensions or fonts swap after the initial render. To fix this, always set width and height attributes on images. If you are using a framework like Next.js or Nuxt, use their optimized image components to prevent layout shifts.

Another common mistake is the massive JavaScript bundle. If your site relies entirely on client-side rendering (CSR), search engine bots have to execute your JS to see the content. While they are better at this than they used to be, it is slower and more prone to errors. Use Server-Side Rendering (SSR) or Static Site Generation (SSG) for any page that needs to be indexed.

Semantic HTML is Not Optional

Many of us have fallen into the div-soup trap. We use a div for everything and style it to look like a header or a button. However, search engines use semantic HTML to understand the hierarchy of your information.

An h1 tag tells a bot what the page is about. An article tag defines a self-contained piece of content. A nav tag identifies the primary navigation. When you replace these with generic divs, you are stripping away the context that bots use to categorize your site.

Here is a quick rule of thumb: if you can remove all the CSS and the page still makes logical sense to a screen reader, your SEO is in a good place. Accessibility and SEO are essentially the same goal: making content machine-readable.

The URL Architecture

Developers often create URLs that make sense for the database but not for a human or a bot. A URL like /product/12345 is useless for SEO. A URL like /product/mechanical-keyboard-blue-switches tells the bot exactly what is on the page before it even loads.

If you are changing your URL structure, never just delete the old ones. This creates 404 errors that kill your ranking. Always implement 301 redirects. A 301 tells the search engine that the content has moved permanently, preserving the "link juice" from the old URL.

Managing the Crawl Budget

Search engines do not spend infinite time on your site. They have a crawl budget. If you have thousands of duplicate pages or a messy internal linking structure, the bot might leave before it finds your most important content.

Use a robots.txt file to tell bots which parts of your site to ignore. Do not let them crawl your admin panel, your search result pages, or your internal API endpoints. This forces the bot to spend its time on the pages that actually bring in users.

The Concrete Takeaway

Stop treating SEO as a post-production task. It should be part of your definition of done for any feature.

Before you merge a PR, ask yourself these three questions:

Does this page shift visually while loading (CLS)?
Am I using semantic HTML tags instead of just divs?
Is the URL descriptive and does it redirect properly if it replaced an old one?

If you focus on these technical foundations, the keyword optimization will actually work. You cannot optimize a site that is slow, inaccessible, or structurally broken.

Stop Building Chatbots: Moving Toward Agentic Content Workflows

Ntty — Sun, 05 Jul 2026 11:00:31 +0000

Most developers start their AI journey by building a wrapper around a prompt. You send a request, you get a response, and you hope it is correct. This is a linear workflow. It works for simple tasks, but it falls apart when you try to produce high-quality technical documentation or SEO-driven content.

When I first tried to automate our blog's technical deep-dives, I used a massive prompt. I told the LLM to "be an expert engineer, use a professional tone, and include code examples." The result was generic fluff. It looked like a marketing brochure because the LLM was trying to guess the right answer in one shot.

To fix this, you need to move from a prompt to an agentic workflow. This means moving from a single call to a loop of planning, executing, and critiquing.

The Problem with Linear Prompts

Linear prompts suffer from the "hallucination drift." If the model makes a mistake in the second paragraph, it will spend the rest of the article trying to justify that mistake to maintain internal consistency. It cannot go back and fix its own logic because it only moves forward.

In a professional content operation, no human writer works this way. You do not write a 2,000 word technical guide in one sitting and hit publish. You outline, research, draft, review, and edit.

Designing an Agentic Loop

An agentic workflow breaks the task into specialized roles. Instead of one prompt, you build a pipeline of small, focused agents that talk to each other.

1. The Researcher Agent

This agent does not write. Its only job is to find facts. It should take a topic and produce a structured list of requirements, API references, and actual code snippets. If you are writing about a specific library, this agent should pull the latest documentation rather than relying on the LLM's training data.

2. The Architect Agent

This agent takes the research and builds a skeleton. It defines the H2s and H3s. It decides where the code blocks go. The goal here is structural integrity. If the outline is weak, the final article will be weak regardless of how good the prose is.

3. The Writer Agent

Now, the writer takes a single section of the outline at a time. By limiting the scope to one heading, you prevent the model from losing focus or skipping details to save tokens.

4. The Critic Agent (The Most Important Part)

This is where the magic happens. The Critic agent is prompted to be pedantic. It looks for:

Generic adjectives (e.g., "powerful," "seamless").
Lack of concrete examples.
Logical gaps in the code.

If the Critic finds an issue, it sends the section back to the Writer with specific feedback. This loop continues until the Critic gives a thumbs up.

Implementing the Workflow

You do not need complex frameworks to start this. A simple Python script with a few different system prompts and a while-loop can handle this logic.

One technical tip: use a structured output format like JSON for the communication between agents. When the Researcher passes data to the Architect, it should be a JSON object with keys like key_concepts and source_urls. This prevents the Architect from getting confused by the Researcher's conversational filler.

The Takeaway for Builders

If you want to automate content that actually ranks and provides value, stop trying to find the "perfect prompt." It does not exist. Instead, build a system of checks and balances.

Focus on the feedback loop. The quality of your output is not determined by the LLM you use, but by the rigor of your Critic agent.

For those of us managing the research side of this, I have been using Citedy (https://www.citedy.com) to keep sources organized and verifiable, which feeds directly into the Researcher agent's context window.

Why Your Indie Project is Stuck in Development Hell

Ntty — Sat, 04 Jul 2026 11:00:32 +0000

I have spent three years building a project that should have taken three months.

For a long time, I told myself I was just ensuring quality. I was building a robust architecture. I was making sure the edge cases were handled. In reality, I was terrified of launching. I was hiding behind my IDE because as long as the project is 'in development', it cannot fail. Once you ship it, the world gets to tell you if your idea is actually useful.

If you are an indie developer and your project has been at 90 percent completion for six months, you are probably trapped in the same loop. Here is how to break it.

The Trap of the Perfect Stack

When we build for a company, we have a manager or a product owner telling us what the priority is. When we build for ourselves, we often prioritize the tech we want to learn over the product the user needs.

I once spent two weeks migrating a small internal tool from a simple REST API to GraphQL because I wanted to get comfortable with the ecosystem. The tool had zero users. I spent forty hours optimizing a query for a database that held ten rows of data.

Stop treating your indie project like a portfolio piece for a FAANG interview. Your users do not care if you used a microservices architecture or if your Redux store is perfectly normalized. They care if the button works and the problem gets solved.

The Feature Creep Spiral

Feature creep usually starts with a thought like, "It would be cool if it also did X."

Then you realize that to do X, you need to change your data model. Then you realize you need a new authentication flow to support X. Suddenly, you are three weeks deep into a feature that was not part of your original value proposition.

Every new feature adds a tax. Not just the time to build it, but the time to test it and the cognitive load of maintaining it. If you keep adding features before your first user signs up, you are just guessing what people want. You are building a solution for a problem that might not exist.

The 'Just One More Tweak' Fallacy

There is a specific kind of anxiety that hits right before you hit deploy. You find a weird CSS bug on a screen size that only three people in the world use. You decide you cannot possibly launch with that bug.

This is a procrastination tactic. Your brain is trying to protect you from the vulnerability of being judged.

Accept that your first version will be ugly. It will have bugs. The UI will be slightly off in some browsers. That is fine. The goal of a V1 is not to be perfect. The goal is to validate that someone actually wants what you are building.

How to Actually Ship

If you are stuck, try these three rules:

The Hard Cutoff: Pick a date. Not a window, but a date. If the project is not live by that Friday at 5 PM, you have failed.
The Feature Freeze: List every feature you think you need. Now, delete half of them. Then, delete half of what is left. Whatever remains is your MVP. Everything else goes into a 'Future' text file that you are not allowed to open until you have ten active users.
The 'Good Enough' Threshold: If a feature works and does not crash the app, it is done. Do not spend another hour on it.

The Takeaway

Shipping is a skill, just like coding. If you never ship, you never learn how to handle feedback, how to debug in production, or how to market a product.

Stop polishing the chrome on a car that does not have an engine. Get it on the road, let it rattle and shake, and fix the parts that actually break based on real world usage. The most successful indie projects are rarely the ones with the cleanest code. They are the ones that solved a real problem and got into the hands of users the fastest.

Stop Building Chatbots: Start Building Agentic Content Pipelines

Ntty — Fri, 03 Jul 2026 13:57:47 +0000

The Chatbot Trap

Most developers start with a chat interface. You build a wrapper around an LLM, add some system prompts, and call it an AI tool. But if you are building for content operations or SEO, a chat interface is actually a bottleneck. It requires a human to sit there, prompt the AI, check the result, and prompt it again.

That is not an agent. That is just a fancy text editor.

Agentic workflows are different. An agent does not wait for you to tell it what to do next. It has a goal, a set of tools, and a loop that allows it to self-correct. Instead of "Write a blog post about React," an agentic pipeline looks like: "Research the current state of React Server Components, find three conflicting opinions, draft a technical comparison, and verify the code snippets against the latest docs."

The Architecture of a Content Agent

To move from a prompt to a pipeline, you need three specific components: a Planner, an Executor, and a Critic.

1. The Planner

The planner breaks the high-level goal into a graph of tasks. If you want to create a technical guide, the planner should not just start writing. It should create a checklist: search for documentation, identify common pitfalls, outline the structure, and draft the sections.

I recommend using a state machine for this. If you use a tool like LangGraph or a simple custom loop, you can track which stage the content is in. If the 'Research' stage fails to find a source, the planner should loop back and try a different search query rather than just hallucinating a fact.

2. The Executor (The Tool Belt)

An LLM alone is a closed system. To make it agentic, you must give it tools. For content ops, this usually means:

A search API (Tavily or Serper) to get real-time data.
A scraper to parse technical documentation.
A code execution environment to test the snippets it generates.

When the executor hits a wall, it should be able to emit a signal. For example, if a documentation page is behind a login or uses a weird JS framework, the executor should report this back to the planner to find an alternative source.

3. The Critic (The Quality Gate)

This is where most builders fail. They trust the first output. A true agentic workflow uses a separate LLM call (or a different model entirely) to act as the editor.

The Critic should have a specific rubric:

Are there any generic phrases?
Does the code actually run?
Is the claim backed by a source?

If the Critic finds an issue, it sends the draft back to the Executor with specific instructions on what to fix. This loop continues until the Critic gives a "thumbs up."

Handling the 'GEO' Problem

Generative Engine Optimization (GEO) is the new SEO. When AI search engines like Perplexity or SearchGPT summarize a topic, they don't just look for keywords. They look for citations, authoritative data, and clear structures.

If your agentic pipeline just scrapes the web and rewrites it, you are creating noise. To win at GEO, your agent needs to synthesize. It should look for gaps in existing content and fill them. Instead of summarizing five articles, the agent should identify where those five articles disagree and explain why.

Practical Implementation Tips

If you are building this today, keep these lessons in mind:

Avoid long prompts. Break your system prompt into smaller, task-specific prompts for the Planner, Executor, and Critic.
Use structured output. Force your agent to return JSON. It is the only way to reliably pass data between different stages of the pipeline.
Log everything. When an agent loops infinitely or goes off the rails, you need to see exactly which tool call caused the drift.

The Takeaway

Stop thinking about AI as a conversation. Think of it as a series of micro-services. The goal is to build a system where the human is the editor-in-chief, not the prompt engineer. When you shift from "Chat" to "Pipeline," you move from generating a few pages of text to running a scalable content operation.

For those of us dealing with the research and citation side of this, I have been using Citedy (https://www.citedy.com) to help manage sources and ensure accuracy in the final output.

Agent-ready short links from the command line

Ntty — Fri, 12 Jun 2026 19:57:06 +0000

Most short-link tools are designed around a dashboard. I did it for agents.

That works when a marketer is setting up campaigns manually. It is awkward when the workflow starts in a terminal, CI job, documentation script, launch checklist, or coding agent.

Lnkgo is a small API/CLI-first link service for branded tracked links.

npm CLI: npm install -g lnkgo
agent skill: npx --yes skills add citedy/lnkgo --skill lnkgo

You can create a short link, generate a QR code, read analytics, and verify a custom domain without opening a dashboard.

Example agent use cases

Create a campaign link:

Create a Lnkgo link for this launch URL and tag it producthunt.

Track a partner page:

Create a partner link, then summarize clicks by referrer tomorrow.

Generate a QR:

Create a tracked link and save a QR code as event-qr.png.

Use a custom domain:

Check my domain status, then create the link on links.example.com.

Summarize analytics:

Fetch analytics for this link id and give me totals, countries, and top referrers.

CLI example

lnkgo create \
  --url https://example.com/launch \
  --tag devto \
  --tag launch

Then use the returned id for QR and analytics:

lnkgo qr "$LINK_ID" --output event-qr.png
lnkgo analytics "$LINK_ID"

REST API example

curl -sS -X POST "https://api.lnkgo.app/v1/links" \
  -H "Authorization: Bearer $LNKGO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: $(uuidgen | tr '[:upper:]' '[:lower:]')" \
  -d '{"url":"https://example.com/launch","tags":["producthunt","launch"]}'

Custom domains

Default links use lnkgo.app.

If you want your own domain, request it, add the returned DNS proof records, and create links on that domain after it becomes active.

Launch limits

Email verification starts with safe starter limits. Domain ownership proof unlocks the launch offer: up to 10 custom domains, 10,000 links/month, 1,000 links/domain/month, 50,000 API calls/month, and 14-day analytics.

Try it here:
https://lnkgo.app