DEV Community: Atul Jalan

After 100s of hours of trial-and-error, I decided to write up a field guide to finding success with AI coding:

Atul Jalan — Wed, 28 May 2025 18:15:28 +0000

Atul Jalan

May 28 '25

A Practical Field Guide to AI Coding

#ai #programming

Comments

5 min read

A Practical Field Guide to AI Coding

Atul Jalan — Wed, 28 May 2025 18:11:27 +0000

I, like most other developers, experienced AI coding in three stages: from initial awe, to deep disillusionment, to finally, a balanced view. LLMs are neither super-intelligence nor vaporware. Annoyingly, they're somewhere in the middle. Truly magical for some tasks, utter garbage for others. Your job as a developer is to build intuition for which is which.

This essay is a field guide to developing that intuition. After hundreds of hits and misses, I've decided to summarize in rank-order the tasks where AI has consistently succeeded, and where it's tended to fall apart.

Though no one can skip the three stages, hopefully this will speed you along.

Green-field tasks (Excellent)

LLMs excel at writing scoped methods that are not dependent on context from your codebase, even when the complexity of the method itself may be high. These kinds of tasks enable models to fully leverage their vast knowledge base without having to consider how it applies to your context.

For example:

Utilities like rate limiters, date formatting, array transformations, etc.
Base UI components like inputs and selects
Regex formulas

In these situations, use AI religiously to one-shot the entire thing.

For the best outcome, write the function or class signature yourself and have the AI fill it in. This will maximize chances that the LLM will adhere to your vision of how the final product should work. For maximum speed, have the model generate just the signature, edit to your liking, then ask it to write the actual code.

Pattern Expansion (Great)

LLMs are great at repeating existing patterns - especially once you've written the first few examples. This works surprisingly well even if the pattern is quite unique to your codebase, since LLMs are fundamentally trained to model and reproduce patterns in data.

For example:

Add more variants to a component once the base exists (e.g. more button types)
Generate additional endpoints or models following existing conventions
Expand schema definitions in an OpenAPI or JSON Schema

Probability of success with this task will depend on two factors:

How formulaic is the task? Less nuance is better here. You want tasks where a clear set of patterns are repeated every time, instead of conditionally repeated based on other aspects of the data.
How organized are the examples? If this is a pattern you will repeat a lot (e.g. API endpoints), it's worth the time to create 2-3 excellent examples that you can throw into context every time.

Documentation (Great)

LLMs are great at producing well-written documentation (e.g. docstrings) for your methods and classes. This task works well because it plays to a core strength of LLMs: compression. Just as they're trained to pack vast amounts of knowledge into a small set of weights, they can also compress logic from lots of code into a high-level explanation.

LLMs are further aided by existing language conventions for how to write docstrings and comments, leaving them less room to freestyle and potentially mess up.

Code Explanation (Good)

LLMs are reasonably effective at summarizing what blocks of code do, even when the code is quite long and spans multiple files. The summaries are rarely perfect, but they tend to be directionally correct, which is often enough to accelerate understanding.

This task once again takes advantage of an LLMs strong compression capabilities.

Don't waste time formatting the prompt or providing tons of additional context. The increase in response quality is often minimal.

Obviously, never trust the explanation word-for-word. The summaries will almost always skip over sections of the source code and confidently misstate logic in a highly believable way. Use this capability as a jumping-off point before diving in, not as the final word.

Technical Spec Review (Good)

Ask LLMs to review your technical planning docs and point out possible issues and edge cases you may not have thought of.

These tasks enable LLMs to map your specific task to the generalized equivalent and pattern-match that against their vast training set. In contrast, asking LLMs to write the document itself will usually perform poorly since the LLM has to map the generalized task to your specific context.

Even if the majority of its recommendations are irrelevant, there will usually be at least one or two points that are worth considering and addressing in the spec.

Debugging (Bad)

LLMs are poor primary tools for debugging. They struggle in situations where the root cause is unclear and context is fragmented. The worst part is that they will confidently hallucinate incorrect solutions, burning your time and spiking your cortisol.

Debugging is generally a process of exploration. You start with minimal knowledge and slowly gain understanding through iterative investigation. LLMs, on the other hand, perform best when given comprehensive context and asked to produce clear outputs.

That said, LLMs can be helpful as an encyclopedia. During debugging, I use a parallel chat window for asking general questions about libraries, language behaviors, or common failure modes. These kinds of queries work well because they don't rely on the model having any contextual knowledge of your codebase.

Multi-file edits (Terrible)

In my experience, success rates drop sharply as soon as the requested edit spans multiple files. I've tested this by comparing how an LLM performs when asked to make an edit across multiple files vs. those same files combined into one larger document. It always does significantly better in the latter case.

I've found it's faster to decompose your task into multiple requests to edit single files. This simplifies the contextual burden to the LLM, and the cognitive load to you as the reviewer.

Conclusion

For me, success with LLMs has had less to do with prompting and more to do with task selection. This has been in contrast to the conventional wisdom that LLM performance hinges almost entirely on the precision and depth of the prompt.

No doubt, there are much more sophisticated workflows for using LLMs. My goal has been to optimize time investment to successful results, not to engage in an exhaustive search for the perfect setup. Besides, the landscape is evolving far too quickly to make such a quest worthwhile.

While online discussion on AI coding skews to the extreme (either AI-first or AI-never), I think most developers are part of a silent majority with a more measured approach. To that group: publish your workflows! There's far too much noise from influencers tweeting about how they're commanding an army of AI agents to build 7 apps in a weekend, and not enough from developers at mature companies explaining how they're using AI coding on real projects in large codebases. Hopefully this guide helps tip the balance in that direction.

This essay was originally published on composehq.com.

Lessons from Scaling WebSockets

Atul Jalan — Fri, 24 Jan 2025 19:20:27 +0000

With the rising demand for sync engines and real-time feature, WebSockets have become a critical component for modern applications. At Compose, WebSockets form the backbone of our service, powering our backend SDKs that enable developers to deliver low-latency interactive applications with just backend code.

But, scaling WebSockets has proven to be far more complex than we expected. Below are some of the most important lessons we've learned along the way.

Handle deployments gracefully

Users should never notice when deployments happen, so WebSocket connections need to persist across deployments. This is a delicate process, and requires robust reconnection logic to deal with unexpected issues. At Compose, we achieve near-zero downtime by following these steps:

Spin up new servers.
Once the new servers are healthy, old servers begin returning 503 Service Unavailable responses to health checks.
After 4 consecutive 503 responses, the load balancer declares the server unhealthy and removes the old servers from the pool. The load balancer health checks every 5 seconds, so this process takes up to 25 seconds.
Old servers send a custom WebSocket close message instructing clients to delay reconnection by a random interval to avoid a reconnection surge.

The custom close message lets clients show users a more accurate message during the ~10 second period where the client is disconnected.
The random delay helps prevent thundering herd issues where all clients reconnect at once. Clients also double the exponential backoff for deployment-related reconnections to account for unforeseen issues.
The close message is delayed by 20 seconds to account for the time it takes for the load balancer to shift traffic.

Once all clients disconnect, the old servers shut down completely.

If you're using a managed service like Render or Railway, you should be especially cognizant that client connections are transferred gracefully during deployments.

Many managed services that tout zero-downtime deployments will wait until all outstanding requests are processed before shutting down a server. Since WebSocket connections are persistent, this can lead to situations in which old servers are active for minutes or even hours after a deploy until the managed service forcibly terminates the process.

Establish a consistent message schema

While HTTP comes with built-in routing conventions (GET /user, POST /company, PUT /settings), WebSockets require developers to define their own schema for organizing messages.

At Compose, every WebSocket message starts with a fixed 2-byte type prefix for categorizing messages.

It's space-efficient (only 2 bytes), while still scaling to 65,536 different types.
It enables clients to reliably slice the type prefix from the message without affecting the rest of the data, since the prefix is always 2 bytes.
It gives us a simple method for upgrading our APIs by versioning message types.

const MESSAGE_TYPE_TO_HEADER = {
  RENDER_UI: "aa",
  UPDATE_UI: "ab",
  SHOW_LOADING: "ac",
  RENDER_UI_V2: "ad",
  /* ... */
}

Additionally, we use delimiters to separate different fields inside the message, which is both faster to encode/decode and more memory-efficient than JSON.

const DELIMITER = "|";

function createDelimitedMessage(type: string, args: any[]) {
  return [MESSAGE_TYPE_TO_HEADER[type], ...args].join(DELIMITER);
}

function parseDelimitedMessage(message: string) {
  const [type, ...args] = message.split(DELIMITER);
  return { type, args };
}

We're lucky that our backend and frontend are written in TypeScript, allowing us to share message schemas between the two and ensure that neither falls out of sync.

Detect silent disconnects with heartbeats

Connections can drop unexpectedly without triggering a close event, leading to a situation in which the client thinks they're connected, but actually aren't. To prevent stale connections, implementing a robust heartbeat mechanism is essential.
We send periodic ping/pong messages between client and server and reconnect in cases where the heartbeat isn't received within some interval.

Our server sends a ping message every 30 seconds, and expects a pong response. In cases where the client doesn't receive a ping every 45 seconds, it immediately drops the connection and tries to reconnect. Similarly, the server closes connections that miss pong responses within 45 seconds.

By monitoring heartbeats on both ends, we detect and handle rare cases where the client side network appears functional but the server never receives responses.

Have an HTTP fallback

WebSocket connections can be unexpectedly blocked, especially on restrictive public networks. To mitigate such issues, Compose uses server-sent events (SSE) as a fallback for receiving updates, while HTTP requests handle client-to-server communication.

Since SSE is HTTP-based, it's much less likely to be blocked, providing a reliable alternative in restricted environments. Plus it still achieves decently low latency, especially compared to short-polling solutions.

Concluding thoughts

There's a whole lot more to scaling WebSockets that we didn't cover here. For example:

Lack of standard tooling: While most frameworks include built-in tools for rate limiting, data validation, and error handling, you'll generally have to implement these features on your own for WebSockets.
Inability to cache responses: Edge networks make it easy to cache HTTP responses close to users, but there's no standard way to accomplish this with WebSockets.
Per-message authentication: Guarding against abuse by ensuring that each message is valid for that user before processing it.

But regardless of the complexity, users expect modern applications to be fast, realtime, and collaborative. And, as of now, there's no better way to achieve that than WebSockets.

At Compose, WebSockets power the entire platform - from the database all the way to the main UI thread. Via our SDKs, developers can generate full web apps from their backend logic. Making sure those apps are fast and performant at scale requires WebSockets. If you're interested in learning more, check out our docs. It takes less than 5 minutes to install the SDK and build your first app.

How we wrote a better debouncer for our UI rendering engine

Atul Jalan — Tue, 21 Jan 2025 20:18:45 +0000

https://composehq.com/blog/optimize-debounce-1-17-25.

I've written a lot of debouncers in my life. Thought I'd share this article on how we wrote a smarter algorithm to debounce updates for UI rendering engine.