programming – My Vibe Coding Projects

One of the techniques I have started to use, is to pit the AI Chatbots against themselves, in a way.

What I mean is, take your idea, or starting prompt, feed it into one of the five AI Chatbots, takes the results, ask another AI Chatbot to improve it.

This ends up being a way of refactoring your code fairly quickly.

Lets take an idea, the one we just had, to create a network scanner, but instead of asking for code, we are just going to ask for concepts and best practices. Generating code can chew up a bunch of credits really quick. Having one AI Chatbot review and improve the concepts/mechanisms given previoulsy by another really can speed things up, catch errors and you end up with more correct code to put into the IDE the first time.

Ok, lets move to C# as our programming platform, console, not WPF, WPF will come later.

We are going to start by asking DeepSeek:

I am working on a project, a local network scanner, it will be a c#, console app, do not write any code, just give me the concepts and best practices for writing the best local network scanner, produce the prompt and the reasoning, once again, no code!

Here was DeepSeek’s response, you might be able to plug this prompt into the chatbot and end up with something pretty good-

Here is the prompt you can use to guide your own work or to ask others for assistance, followed by the reasoning behind each design choice.

Prompt for Developing a Local Network Scanner (C# Console App)

“Design a high-performance, non-intrusive local network scanner in C#. The scanner must discover active IP addresses, MAC addresses, hostnames, and open ports within a configurable subnet (e.g., 192.168.1.0/24). Requirements:

Speed – Scan a /24 subnet in under 10 seconds.

Reliability – Handle unreachable hosts, timeouts, and partial responses gracefully.

Non-intrusiveness – Use standard ICMP, ARP, and TCP connect scans without aggressive rates that trigger IDS/IPS.

Cross-platform – Work on Windows, Linux, and macOS (using .NET 6+).

Output – Console table and optionally CSV/JSON export.

Explain the best practices for:

Concurrency patterns (async, parallel, semaphores)

ARP vs ICMP vs TCP SYN for host discovery

MAC address resolution on different OSes

Port scanning techniques (connect scan, half-open, service detection)

Handling administrative privileges (raw sockets vs .NET built-in)

Timeout and retry strategies

Data structures for deduplication and result aggregation

Rate limiting to avoid network flooding

Real-time progress reporting in console

Graceful cancellation (Ctrl+C)

Unit testing network-dependent code (mocking, test doubles)”

Reasoning (Why These Concepts & Best Practices?)

1. Concurrency Patterns (Async, Parallel, Semaphores)

Why: A naive sequential ping of 254 IPs with a 1-second timeout takes >4 minutes.
Best practice: Use SemaphoreSlim to limit concurrent tasks (e.g., 50–100) to avoid overwhelming the network stack or local CPU.
Async Task.WhenAll over Parallel.ForEach (better for I/O-bound operations like network requests).
Partitioning the IP range into chunks reduces contention on shared data structures.

2. Host Discovery Method

ICMP (Ping) – Most straightforward, but often blocked by firewalls. Use System.Net.NetworkInformation.Ping asynchronously.
ARP – More reliable on local subnet (unfiltered), but requires raw sockets (Windows: SendARP via P/Invoke; Linux: reading /proc/net/arp after sending ARP requests).
TCP ping (connect to common ports 80/443) – Good fallback when ICMP is blocked.
Best practice: Combine ICMP + ARP; if both fail, try TCP connect to port 443.

3. MAC Address Resolution

Windows: SendARP (iphlpapi.dll) – works without raw sockets.
Linux/macOS: Read /proc/net/arp or use arp -n (but parsing is slow). Better: craft raw ARP requests using Socket with ProtocolType.Raw (requires root).
Alternative: Capture ARP replies from the network passively during ping sweeps (promiscuous mode – complex).
Best practice: For cross-platform, prioritize OS-specific implementations behind an interface (IMacResolver).

4. Port Scanning Technique

TCP Connect Scan (Socket.ConnectAsync) – Works everywhere without admin rights, but slower and more detectable.
TCP SYN scan (half-open) – Faster and stealthier, but requires raw sockets (admin/root).
Service detection – After connection, send a probe (e.g., “HEAD / HTTP/1.0\r\n\r\n”) and read banner.
Best practice: Default to TCP Connect for simplicity; offer SYN scan as an opt-in for advanced users. Scan only top 100–1000 ports unless specified.

5. Administrative Privileges

Without admin: Can do ICMP, TCP Connect, and DNS resolution.
With admin: Can use ARP (Windows), raw sockets (SYN scan), and send custom Ethernet frames.
Best practice: Design the scanner to work in both modes – detect privilege level at startup and degrade gracefully. Use OperatingSystem.IsWindows() and environment checks.

6. Timeout & Retry Strategy

Initial ping timeout: 500–1000 ms.
Port scan timeout: 200–500 ms per port.
Retries: 1 retry for unreplied hosts (different source port), 0 retries for ports (faster to move on).
Exponential backoff not needed on a local network – keep fixed, small timeouts.

7. Data Structures for Aggregation

Use ConcurrentDictionary<IPAddress, HostInfo> for thread-safe accumulation.
HostInfo contains: MAC, hostname, list of open ports, response time, last seen timestamp.
Deduplicate ARP and ICMP results – prefer ARP MAC if available.

8. Rate Limiting & Non-Intrusiveness

Why: Burst of 1000 packets/sec can trigger consumer router defenses or switch flood protection.
Implementation: Use SemaphoreSlim with a timer-based release (e.g., permit every 10 ms) or Task.Delay between batches.
Better: Adaptive rate – start slow, increase until loss appears, then back off.

9. Real-Time Progress Reporting

Use Progress<T> or an IProgress<string> updated from async tasks.
Console rendering: Overwrite same line using \r for percentage, but lock the console for table updates.
Show: [IP range] 45/254 hosts active | 1240/25400 ports scanned | ETA 3s

10. Graceful Cancellation (Ctrl+C)

Pass a CancellationToken to all async methods.
Register Console.CancelKeyPress to trigger cancellation and wait for pending tasks with a timeout.
On cancel, print partial results instead of crashing.

11. Unit Testing Network-Dependent Code

Problem: You can’t test actual network scans in unit tests.
Solution: Abstract network operations behind interfaces (IPingService, IPortScanner, IMacResolver).
Use Mock<T> (Moq) or Fake implementations that return predefined responses.
Test logic separately: IP range parsing, result deduplication, output formatting, retry policies.

12. Additional Best Practices (Not in prompt but critical)

DNS resolution in parallel – after host discovery, resolve names with Dns.GetHostEntryAsync (beware of timeouts).
Output format – Use Spectre.Console or ConsoleTables for clean tables; export to CSV/JSON for further analysis.
Configuration – Allow CIDR notation (192.168.1.0/24), IP range (192.168.1.1-254), or list of IPs.
Logging – Use ILogger with debug level for diagnostics, but avoid slowing scan.
Resource cleanup – Dispose sockets and ping instances.
Network interface detection – Automatically find local active interface (Wi-Fi/Ethernet) and its subnet.

Final Note

No code was written, as requested. The above concepts give you a complete architectural blueprint. When you implement, start with a synchronous working version, then add async, concurrency controls, and finally privilege escalation features. Always test on a lab network first.

But why not ask Copilot to try and improve it?

I asked DeepSeek the folowing question – I am working on a project, a local network scanner, it will be a c#, console app, do not write any code, just give me the concepts and best practices for writing the best local network scanner, produce the prompt and the reasoning, once again, no code! , and got the following response, can you improve it?

It gave me a nice log response, but then I asked it for a side by side comparison and it gave me this –

Category	DeepSeek’s Version	Improved Version
Prompt Quality	Long, slightly scattered; mixes requirements with explanations; less polished.	More concise, structured, and professional; clearer requirements; easier for another AI or engineer to follow.
Organization	List‑style reasoning with uneven depth; some redundancy.	Cohesive architectural flow; each section builds on the previous; no redundancy.
Clarity of Tradeoffs	Mentions ARP/ICMP/TCP differences but not deeply contextualized.	Explicit “when it works / when it fails / why it matters” for each technique.
Cross‑Platform Considerations	Present but fragmented.	Centralized, interface‑driven approach; clearer OS‑specific strategies.
Privilege Handling	Covered but lightly.	Strong emphasis on privilege detection, fallback behavior, and capability tiers.
Concurrency Guidance	Good but focused mostly on raw speed.	Broader: async patterns, contention reduction, batching, adaptive throttling.
Rate Limiting	Basic semaphore + delay.	Adds adaptive rate control, network‑friendly scanning philosophy.
Port Scanning	Good overview but leans technical.	Clearer hierarchy: default vs. advanced modes; practical guidance for real networks.
Testing Strategy	Mentions mocking.	More complete: abstraction layers, deterministic test behavior, separation of concerns.
Additional Best Practices	Some extras included.	More comprehensive: interface detection, scan profiles, structured output, DNS strategy, logging discipline.
Readability & Tone	Informative but dense; feels like notes.	Polished, readable, senior‑engineer tone; easier to digest.
Overall Value	Solid technical info.	A more complete architectural blueprint with clearer reasoning and better real‑world applicability.

Now I will give Claude (my preferred choice for complete working code) the prompt from Copilot, ask it to improve it and then produce a step by step guide!

My original intent, build a network scanner, has now been improved twice before generating the complete code.

I took those results, added some refining statements, fed it all into Chat GPT for another complete solution.

The original code it put out had 2 erros that it had to correct –

Alright—here’s a fully corrected, beginner-safe, copy-paste complete version that fixes:

❌ FilterEnum error
❌ Invalid subnet crash
✅ Auto-detect network properly
✅ Lets user override
✅ Validates input (won’t crash anymore)

This is the version you should be using in Visual Studio.

But the program did run.

The real point of this exercise is to demonstrate that you can achive better results sometimes by having another ai chatbot check your project/code and refine it before using your prefered bot to actually create it!

Tag: programming

AI Chatbot Thunderdome