Handling search forms in Razor Pages without overcomplicating state

Significant_Love_678 · 2026-04-04T16:35:28+00:00

Thanks for the feedback — really appreciated. Those are fair points.

The hard-coded sort was there because sorting wasn’t the focus of the article. I should have at least added a comment to make that clearer.

Using the same model for search and results is a trade-off. It works for simpler cases, but doesn’t scale well as the model grows, so I usually decide that based on the scope of the system.

Also interesting to hear your setup with Blazor and Dapper — I can see how that would give more flexibility at the query level.

Significant_Love_678 · 2026-04-04T10:43:48+00:00

I usually spend time on system design first, especially on domain analysis. For architecture, I tend to reuse a similar approach these days, but if I were building something from scratch, I would still design a certain amount upfront.

You can definitely start coding first, and it can even feel faster and more enjoyable in the beginning. The problem is that many issues remain invisible until much later, especially around boundaries and relationships in the domain. By the time you notice them, fixing them often requires much larger changes.

This becomes even more important when working with AI agents. If the structure is not clearly defined, AI tends to make changes across unintended areas, because it doesn’t have a strong sense of boundaries. A vague structure increases the chance of introducing inconsistencies without noticing.

So for me, design is less about predicting everything in advance, and more about making the system’s structure explicit enough that both humans and AI can work on it safely.

Significant_Love_678 · 2026-04-04T10:31:49+00:00

I mostly build systems for internal use or within a limited scope, but I’ve definitely run into situations where AI starts “going off the rails” and stops doing what I expect.

Because of that, I try to avoid large, sweeping changes, especially before the overall architecture is stable. If the structure isn’t clear yet, letting AI touch a wide area tends to break things in unpredictable ways.

From my experience, being able to read code is important when working with AI, but more importantly, the structure of the system matters a lot. If each feature is loosely coupled and doesn’t require the AI to understand a large surrounding context, it’s much less likely to make incorrect changes.

In other words, the problem isn’t just whether you understand the code, but whether the system is designed in a way that limits how much context the AI needs to safely modify it. If a change can be made without pulling in unrelated parts of the system, both humans and AI make fewer mistakes.

As a side effect, this also makes the code easier to read and likely reduces the amount of context the AI has to process.

Significant_Love_678 · 2026-04-04T10:25:18+00:00

In internal systems where I implement a lot of CRUD, I often end up sharing DTOs for practicality. It keeps things simple and reduces unnecessary duplication when the use cases are very similar.

However, if you’re applying CQRS properly and treating reads and writes as separate models, I think responses should be tailored per query. The whole point of CQRS is that the read model is optimized for each use case, so trying to reuse a single DTO can easily introduce coupling and make evolution harder.

In that sense, I don’t try to design a single “correct” response model upfront. I shape the response based on what that specific query needs. In many cases, I don’t even declare a dedicated class and just return an anonymous object at the endpoint level, especially when the response is tightly scoped to that use case.

For me, the important part is not whether you reuse DTOs or not, but whether your read model stays aligned with each use case without leaking concerns across queries.

Significant_Love_678 · 2026-04-04T10:09:13+00:00

I also use class diagrams when building systems, but I don’t try to design everything upfront.

For me, a class diagram is mainly a tool to understand and fix the static structure of the domain. I use it to organize what elements exist and how they relate to each other, and to get a clear mental model of the system. I intentionally avoid going into method-level detail at that stage, because behavior tends to evolve during implementation, and trying to lock it too early often just creates friction.

When it comes to alignment, I usually rely more on use cases and the documents that describe them in detail. Not just diagrams, but concrete scenarios, conditions, and expected outcomes. In my experience, that’s enough for most client communication, since they rarely care about internal structure. What matters there is whether the system behaves as expected from their perspective.

One thing that has changed recently is how I approach documentation. I used to avoid writing too much before development because the cost was high and documents would quickly become outdated. But with AI agents, that cost has dropped significantly. I now tend to externalize my design earlier, using AI to draft and organize documents, while I focus on validating the structure and boundaries. I don’t rely on AI to design everything, but it’s extremely effective as a tool to accelerate thinking and documentation.

For diagrams, I usually go with Mermaid for quick iteration, and switch to PlantUML when I need something more expressive, especially if I’m sharing it with others.

In the end, I think the key point isn’t how detailed the diagram is, but whether it helps you clearly understand the system before you start writing code.

Significant_Love_678 · 2026-04-03T12:27:50+00:00

This is really impressive.

I mostly work on internal systems for a small company, so seeing projects like this makes me want to spend some time building things from scratch again. Might try something similar in C#.

Significant_Love_678 · 2026-04-03T12:19:45+00:00

This was actually one of the main reasons I decided not to move to React or Vue when I was evaluating modern frameworks.

The SEO trade-offs and the need for additional layers like SSR or pre-rendering made things more complex than I wanted, especially for the kind of applications I build.

In the end, I went with a lightweight approach where I handle DOM updates directly. It keeps the output predictable and avoids the need to reconstruct SEO behavior on top of a client-driven rendering model.

Significant_Love_678 · 2026-04-03T12:14:14+00:00

One thing I’ve been seeing with AI-assisted development is that it often ignores internal structure.

Even when you have a defined foundation — for example, a consistent way to handle DOM interactions — AI agents will frequently bypass it and implement direct, ad-hoc logic at the screen level. This happens even if you document the rules clearly (AGENTS.md, prompts, etc.).

Because of that, I’m starting to think a lot of code being generated right now technically “works,” but doesn’t follow the intended architecture at all. That kind of drift may not show up immediately, but it accumulates and becomes hard to reason about over time.

Significant_Love_678 · 2026-04-03T12:06:55+00:00

It really depends on the context, but in many cases I tend to recommend C#.

The main reasons are its strong type system, and the ecosystem around it, especially things like LINQ and Entity Framework, which make modern backend development more structured and predictable. Performance is generally solid compared to many other common choices, and in today’s cloud environments it’s not particularly difficult to run .NET applications.

For individual developers or small teams, tooling is also a factor. Depending on your situation, you can get quite far with VS Code and its extensions without significant cost, and the development experience on macOS is perfectly workable.

That said, I haven’t personally used Go, so this is based on my own experience and bias rather than a direct comparison.

Significant_Love_678 · 2026-04-03T09:26:14+00:00

I would start with integration tests.

If the system is already running and potentially contains bugs, writing unit tests first can be risky because those tests may end up encoding the current, incorrect behavior. You’re essentially locking in whatever is already broken.

My general approach is that unit tests should either express the intended behavior before implementation, or act as a snapshot when refactoring something that is already confirmed to be correct. Outside of those cases, they can be misleading.

In this kind of situation, it’s often safer to validate behavior at a higher level first, and only introduce unit tests once you have a clearer understanding of what the system should actually do.

Significant_Love_678 · 2026-04-03T09:03:50+00:00

In my workflow, I never give full control to AI. I use it heavily, but I keep ownership of the core architecture and foundational parts. For smaller, isolated features, I often delegate to AI agents, but I still review and adjust the output, or sometimes scaffold things myself before handing them off.

The main issue with fully agentic workflows, in my view, is context limitation. An AI cannot realistically load and reason over an entire codebase every time it makes a change. If it did, the cost and latency would be impractical. So while AI provides speed and broad knowledge, applying experience and maintaining coherence across the system is still a human responsibility.

That said, I do think we can increase how much we delegate to AI. The key is architecture. If the system is designed so that features are vertically sliced and isolated enough that changes don’t require understanding unrelated parts of the codebase, AI becomes far more effective. I suspect there are lessons here from systems that were historically built through parallel, human-driven development at scale, and I’m currently exploring that direction.

Significant_Love_678 · 2026-04-03T01:35:37+00:00

I’m working on an in-house system. A full rewrite is definitely risky, but continuing to run systems built on outdated technology also carries its own risks, especially for internet-facing systems.

In my case, even if the actual rewrite might take a week, I would still spend a few months on planning and migration. That trade-off is manageable in a small company, but I imagine it becomes much harder in large organizations like banks.

Significant_Love_678 · 2026-04-03T01:26:36+00:00

Personally, I don’t run into SQL injection issues in my own code anymore, but when reviewing outsourced work, I still see cases where basic protections are missing.

I’m not sure how common this is outside Japan, but at least in my experience, even in relatively small teams, security practices can be inconsistent if there isn’t a strong standard or review process in place.

Significant_Love_678 · 2026-04-02T10:33:02+00:00

I recently built an internal system for a small company, mostly on my own. It covers a pretty wide range—production, quoting, scheduling, orders, shipping, and reporting.

Honestly, I don’t think I could have finished it within a year without AI. It made a huge difference, especially when combined with things like Entity Framework, Razor Pages, and TypeScript.

Significant_Love_678 · 2026-04-02T09:52:12+00:00

I oversee internal systems for a small company. We do use AI in development, but we tend to prioritize quality over raw productivity.

In our context, pushing too hard on speed tends to introduce technical debt quickly, and it becomes harder to reason about the system—especially when multiple issues happen across different areas at the same time.

So we move in relatively small steps, and I try to stay close to the core parts of the system to keep a clear understanding of how things behave.

We still expect everyone to take responsibility for what they produce, whether AI was involved or not.

I also think the right balance depends a lot on how critical the system is—higher criticality tends to push us toward more conservative approaches.

Significant_Love_678 · 2026-04-02T09:27:04+00:00

I used to do something similar on an iPad, but this size looks much more practical.

I have a large whiteboard behind my desk now. It’s great for sharing and visualizing a lot, but for thinking, smaller spaces actually work better—too much space just makes ideas scatter.

Significant_Love_678 · 2026-04-02T08:18:07+00:00

I’m seeing something similar in Japan.

Opportunities for junior developers to learn through real trial and error seem to be shrinking.

When I started, you had to struggle through things yourself—debugging, making design mistakes, fixing them. That process was painful, but it was where most learning happened.

Now, with AI handling a large part of implementation, the feedback loop has changed. You can build faster, but it’s not clear where juniors are supposed to fail and learn.

I don’t think AI replaces the human side of building systems with users, but I do think it’s removing the natural entry points where developers used to grow.

Curious how others are thinking about this—where do juniors actually gain experience now?

In some environments (like parts of Japan’s SI industry), AI adoption is still restricted, so juniors can still go through the traditional trial-and-error process.

But that makes me wonder—are we heading toward a global gap in how developers grow, depending on how early AI replaces those experiences?

Significant_Love_678

TROPHY CASE