For example, a service that reads files from a specific group of storage buckets can be given access to only those buckets instead of the entire project. If its credentials are exposed or the service is compromised, the potential impact is limited to a smaller set of resources.

This makes least privilege useful for reducing the scope of security incidents and preventing accidental access or changes to unrelated resources.

In practice, implementing it often involves creating separate identities and narrowly scoped permissions. A service account might access only buckets with a specific prefix. A database user might access only one schema or a subset of tables. A Kafka producer might write only to the topics it uses.

These are just a few examples of least privilege in practice.

During a large cloud migration, these identities and permissions may need to be created for dozens or hundreds of services. That is when platform limits that rarely matter at a smaller scale can become a problem.

Some limits can be increased. Others depend on the pricing tier. And some require a different architecture.

Here are three examples of access-control limits you might encounter during a large-scale migration—and some options for working around them.

1. GCP’s 20 Conditional IAM Bindings Limit

Google Cloud IAM Conditions let you restrict a principal’s access based on attributes such as a resource’s name or type.

Imagine a migration service account that needs to read only from Cloud Storage buckets with a particular prefix. A conditional binding can grant it the Storage Object Viewer role only when the bucket name matches that prefix.

This is a conditional binding in action: the principal and role remain the same, but a condition limits where the access applies.

However, GCP allows only 20 bindings in the same allow policy when they have:

• The same principal

• The same role

• Different conditions

This is a fixed limit. It cannot be increased.

If the same service account and role require separate conditions for different groups of resources, the first 20 bindings may work, but adding the 21st can fail.

Once that happens, the permission model must change. One option is to grant the role directly at the resource level instead of continuing to add conditional bindings to the project-level policy.

A permission model that works well for a few groups of resources may not work at a larger scale.

Google Cloud: IAM quotas and limits

2. MongoDB Atlas’s 100 Database Users Limit

Creating a separate MongoDB Atlas user for each service gives every service its own credentials and permissions.

For example, an orders service may have read and write access to order-related collections, while a reporting service receives read-only access to a smaller subset of data. Their credentials can also be rotated or revoked independently.

MongoDB Atlas allows up to 100 database users per project.

Imagine migrating 80 services and creating one database user for each. That already uses 80 of the 100 available users.

Now add developer accounts, CI/CD identities, operational tools, legacy integrations, and temporary migration jobs. The remaining 20 users can disappear quickly.

MongoDB recommends contacting Atlas Support when more than 100 users are needed. However, its public documentation does not guarantee an increase or specify a higher maximum.

Possible first steps include removing unused users and reviewing whether any identities can be consolidated without weakening the intended access controls. If that is not enough, contact Atlas Support early to understand what options are available beyond 100 users.

MongoDB Atlas: Configure Database Users

3. Confluent Cloud’s Kafka RBAC Role Binding Quotas

Confluent Cloud uses RBAC role bindings to control which Kafka resources a principal can access.

Imagine an order-processing service that:

• Consumes from the orders-created topic

• Uses the order-processing consumer group

• Publishes to the orders-processed topic

Its service account may need separate role bindings for each type of access. This allows the service to consume and publish the messages it needs without granting access to unrelated topics or consumer groups.

The number of cluster-level RBAC role bindings with Kafka permissions depends on the cluster type:

• Basic, Standard, Enterprise, and Freight: 500 per cluster

• Dedicated: 25,000 per cluster

If a service needs an average of three bindings, 170 services in the same Kafka cluster could require around 510—more than the 500-binding limit available on several cluster types.

The exact number will vary, but the multiplication is easy to miss when permissions are created one service at a time.

Possible options include consolidating bindings through shared resource prefixes where appropriate, requesting a quota increase if one is available, or moving to a Dedicated cluster. The last option can significantly affect cost.

Access-control requirements should therefore be considered when choosing a cluster, not only throughput and storage.

Confluent Cloud: Service quotas

Final Thoughts

Least privilege is worth aiming for. By limiting what each identity can access, it can improve the security of your services and production environments. However, the identities and permissions used to implement this it are not unlimited.

Before migrating services at scale, count the services and resources that will need access. Estimate how many users, identities, and role bindings that access model will require.

Then design a model that remains granular without exceeding the platform’s limits. If the numbers do not fit, determine early whether the limit can be increased, requires a higher tier, or calls for a different design.

Finding a limit early gives you options. Finding it mid-migration can mean delays, redesigns, or unexpected costs.

Something as a Service. Something else as a Service. And usually, there's an acronym to go with it.

So what do they actually mean?

Let's look at the problem each one solves, what you manage, and what the provider manages for you.

First, what does “as a Service” mean?

At its core, “as a Service” means that instead of owning, building, or managing something yourself, a provider offers it to you as something you can use.

Think about email.

A company could build its own email application, run the servers behind it, store all the messages, maintain the software, handle security updates, and keep everything available. Or it could simply use Gmail, while Google takes care of most of what is required to make the email service work.

Cloud service models apply this same idea at different levels.

IaaS — Infrastructure as a Service

Your application needs a computer somewhere to run on.

Traditionally, that could mean buying a physical server, finding somewhere to keep it, connecting it to the network, maintaining it, replacing hardware when it fails, and buying more servers when you need more capacity.

But what if you could simply rent the computing infrastructure you need?

That's essentially Infrastructure as a Service (IaaS). Instead of owning the physical machines, you get computing resources from a cloud provider.

With Infrastructure as a Service, your cloud provider allows you to create virtual machines to run your applications. The provider takes care of the physical hardware, while you still manage the operating system, installed software, and your application.

In plain English: give me a computer to run my stuff on without making me own the physical computer.

On AWS, Amazon EC2 is an IaaS offering. On Google Cloud, Compute Engine fills a similar role.

PaaS — Platform as a Service

IaaS saves you from owning the physical infrastructure. But what if you don't want to manage the virtual machine either?

Maybe what you really want to say is: Here's my application. Please run it.

That's the basic idea behind Platform as a Service (PaaS).

With PaaS, you deploy your application while the platform takes care of much of what is required to run it. You don't need to start by creating a server, installing an operating system, configuring a web server, and setting up all the infrastructure yourself.

A classic example is Heroku: you deploy your application, and Heroku takes care of much of what is needed to run it.

The same idea exists within the major cloud providers. Elastic Beanstalk is an AWS PaaS offering, while App Engine provides a PaaS option on Google Cloud.

In plain English: here's my application—run it for me.

FaaS — Function as a Service

Sometimes you don't need an entire application running all the time. You have a piece of code that only needs to run when something happens.

For example:

• An email is received → process it.

• A photo is uploaded → resize it.

• A user signs up → send a welcome email.

• A payment is completed → generate a receipt.

In other words, you want the cloud to perform an action on your behalf when something happens.

You could keep a server running all day waiting for one of these events. Or you could simply say: when this happens, run this function.

That's the basic idea behind Function as a Service (FaaS).

With FaaS, you provide the function and the cloud provider takes care of the infrastructure needed to run it. You don't choose a server or keep one running yourself. You focus primarily on the code you want to execute.

This approach is commonly known as serverless computing. Serverless doesn't mean there are no servers. There are—you're simply not responsible for managing them.

💡 Tip: FaaS is one form of serverless computing, but serverless is a broader term that includes other types of cloud services as well. We'll explore that distinction in a future article.

On AWS, Lambda is a FaaS offering. On Google Cloud, Cloud Run functions provides this capability.

In plain English: when this happens, run this code for me.

SaaS — Software as a Service

What if you don't want to manage the infrastructure, deploy an application, or write the code? You just want to use the software.

That's Software as a Service (SaaS).

With SaaS, someone else builds, hosts, and operates the software. You simply access and use it.

Gmail is a good example. You don't need to build an email application, maintain an email server, or worry about the infrastructure behind it. You simply use Gmail while Google takes care of running and maintaining it.

The same is true of products like Slack, Dropbox, Salesforce, and many of the software tools we use every day.

SaaS is commonly subscription-based. You might pay for the subscription yourself, or your company might pay for it and give you access.

💡 Tip: Subscription is common, but it's not what makes software SaaS. SaaS can also be free.

💡 Tip: Installing software on your device doesn't mean it isn't SaaS. Slack, for example, is still SaaS when you use its desktop or mobile app. The installed app is simply one way to access the software that Slack hosts and operates.

In plain English: I just want to use the software. Someone else takes care of running it.

Cloud “as a Service” at a Glance

If you want a quick way to remember how these models differ, think about how much you're responsible for managing versus how much the provider manages for you.

Final Thoughts

The next time you encounter another “as a Service,” try asking:

What problem does it solve? What is being provided? And what will I be responsible for managing?

Answering those questions can make the acronym much easier to understand—and remember.

Software development is easier because of AI. But making something easier doesn't mean removing all the challenges. Sometimes it means replacing old ones with completely different ones.

After working this way for a while, I've realized there are quite a few new things we're learning to deal with.

The productivity bar keeps getting higher

AI makes developers faster, but as AI increases how quickly developers can deliver, expectations around productivity increase with it. If something used to take a week and can now be done in three days, eventually three days becomes the expectation.

The time AI saves doesn't necessarily become extra time for understanding an implementation, improving tests, reviewing architecture, or learning something new. Sometimes it just creates room for more work.

When the expectation is to continuously produce more, deeply understanding everything you're shipping can start feeling optional. The feature works. The tests pass. AI can explain the implementation whenever you need it. Do you really need to understand every piece of it?

Probably not. But understanding almost none of it isn't a great alternative either. The challenge is finding the right balance between understanding every line of code AI produces and having only a high-level understanding of what you're shipping. Where that balance sits will depend on the change, its complexity, and the risk involved.

We can produce code faster than humans can review it

AI can generate a substantial amount of code incredibly quickly. But when a human reviews that code, they still need to understand what changed and whether it makes sense.

That can mean more PRs, larger PRs, and more code for reviewers to process. The amount of code we can produce has increased much faster than our capacity to deeply review it.

AI reviewers can make "done" harder to reach

AI code reviewers can help us keep up with the increasing amount of code being produced by identifying vulnerabilities, missing validations, defects, unhandled failures, and edge cases we might otherwise miss. They don't replace human reviews, but they add another valuable layer of review—and another layer of feedback to get through.

Fix comment. Push. New review. Fix another comment. Push. New review. Now there are three more things to consider.

Eventually you're wondering: Are we meaningfully improving this feature, or are we just trying to make the bot happy?

An implementation that handles the most common cases and provides value can be exactly the right engineering decision. We can ship, learn from how the feature is actually used, and address additional edge cases as we iterate instead of trying to solve everything upfront.

We can build things we don't fully understand

Historically, implementing something generally required you to understand it well enough to write it. Those two things are no longer tightly coupled.

Today you can work in a language you barely know, use an unfamiliar framework, or implement a pattern you only partially understand. AI can explore the codebase, propose a solution, write the implementation, generate the tests, and fix the errors.

That's incredibly powerful, but it creates a strange situation: our ability to produce sophisticated solutions can exceed our ability to independently evaluate them.

Being polyglot is easier. Being an expert isn't.

AI has dramatically lowered the barrier to working across technologies. Need some Python? Terraform? A Kubernetes configuration you've never written before? AI can get you surprisingly far.

But there's an important difference between being able to build something with a technology and understanding that technology well enough to recognize when something is subtly wrong.

The further we move outside our areas of expertise, the more we're relying on AI not only to produce the implementation but sometimes to tell us whether its own implementation is good.

Giving AI the right context is now part of the job

The solution AI proposes can change dramatically depending on the context available to it. Give it access to one repository and it may propose a perfectly reasonable solution. Add another repository involved in the same flow, and the right solution might look completely different.

AI can reason about the context it has, but it doesn't necessarily know what important context it's missing.

Even when you start with the right context, keeping it throughout a complex implementation can be challenging. Conversations get long, context gets compacted, and important requirements, architectural decisions, or conventions can get lost.

Part of AI-assisted development is now context management: making sure AI has the right information to begin with and that important context isn't lost along the way.

Sometimes you have to look beyond AI

AI can be incredibly good at debugging, but I've run into difficult issues where it keeps pointing me toward the same set of possible causes and solutions. You try them, provide more information, and somehow end up back in the same place.

At some point, you have to break that cycle. I've had to step away from the AI conversation, search the web, dig through Stack Overflow, or read documentation to find information that leads to a different hypothesis or potential root cause. From there, you can bring AI along again, this time in a new direction.

AI can be confidently wrong

Sometimes AI confidently tells you that a library behaves a certain way when it doesn't. Sometimes it describes functionality that doesn't exist. Sometimes the answer is mostly correct but misses the piece of nuance that actually matters for your problem.

The more frequently AI gives us correct answers, the easier it becomes to trust the incorrect ones too. Knowing when not to trust the answer is becoming an increasingly important engineering skill.

We're becoming less familiar with our own codebases

When I manually explored a codebase and implemented something, I naturally built a mental map along the way. I remembered where things lived, which service called what, and that weird piece of logic because I had spent two hours debugging it.

An agent can now search the repository, identify the relevant files, explain them, modify several of them, run the tests, and get the feature working. I understood what happened at the time, but ask me two weeks later where that logic lives? I might have to ask AI again.

We can interact with much larger portions of a codebase without necessarily developing the same familiarity with them. We can ship more changes while accumulating less knowledge per change.

Understanding something doesn't mean we'll remember it

AI explains something. I read it. Everything clicks. Ahhh. That makes perfect sense. At that moment, I genuinely understand it. A few weeks later? I barely remember it.

Some of the friction AI removes—searching through documentation, experimenting, getting something wrong, debugging it, trying again—is also the friction that used to make concepts stick.

Removing that friction makes us faster, but there's a tradeoff there that I don't think we fully understand yet.

Our debugging skills are getting less practice

When something breaks now, one of my first instincts is to ask AI. And why wouldn't it be? AI can inspect logs, trace execution paths, search the codebase, generate hypotheses, and frequently find the problem faster than I could manually.

But debugging, reading unfamiliar code, forming hypotheses, and knowing where to look when the obvious solution isn't working are skills developed through repetition. If AI performs more and more of those repetitions for us, what happens when we encounter the problem it can't solve?

Technical debt can move faster too

Outdated documentation, poor abstractions, inconsistent conventions, and technical debt all existed long before AI-assisted development. What AI can change is the speed at which they accumulate.

When a team can generate and ship significantly more code, bad patterns can spread faster too. Documentation can become outdated faster, architectural inconsistencies can multiply faster, and developers working across technologies they don't deeply understand can unintentionally introduce patterns that don't quite belong.

AI didn't invent these problems but It can accelerate them.

Final Thoughts

AI-assisted development has made our jobs easier, but it has also introduced challenges we didn't have before.

The interesting question now is how we navigate those challenges without losing the engineering judgment and skills we still need.

That's something I'm still figuring out—and perhaps something we need to talk more about.

What about you? What challenges have you run into since you started using AI for development? Do any of these resonate? I'd love to know.

Understanding these concepts provides a useful foundation for thinking about application security.

Here are 10 of them and the problems they're designed to solve.

1. HTTPS and encryption in transit

When a browser communicates with a web application, information travels across a network.

That information might include passwords, authentication cookies, personal information, or application data.

HTTPS encrypts that communication while it travels between the browser and the server.

Without HTTPS, someone capable of intercepting the traffic may be able to read or manipulate it.

Today, HTTPS is a standard part of deploying web applications. Modern hosting platforms and certificate authorities have also made obtaining and renewing TLS certificates considerably easier than it once was.

💡 What is a TLS certificate?

TLS stands for Transport Layer Security. A TLS certificate is a digital certificate that identifies the server behind a website. It allows the browser to verify that it is communicating with the expected server and helps establish an encrypted connection between them.

Once that secure connection is established, the information exchanged between the browser and the server is encrypted, preventing someone intercepting the traffic from simply reading it.

The important idea is that sensitive information needs protection not only when it's stored, but also while it's moving between systems.

2. Authentication and authorization

Once a request reaches an application, two important questions are: who is making the request, and what are they allowed to do?

Authentication and authorization solve these two related but different problems.

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to access?

Imagine an online store where customers can log in and view their orders.

Sarah logs in successfully. The application verifies her credentials and now knows that the person making requests is Sarah.

That's authentication.

Sarah opens one of her orders, which is available through an endpoint like:

/orders/123

Order 123 belongs to Sarah, so she should be able to access it.

Now imagine order 124 belongs to another customer.

If Sarah changes the URL to:

/orders/124

and the application returns that order simply because she is logged in, there's a problem.

The application correctly authenticated Sarah—it knows exactly who she is—but it failed to check whether Sarah is authorized to access order 124.

That's an authorization vulnerability.

This type of vulnerability is commonly associated with IDOR (Insecure Direct Object Reference): an application exposes a reference to a resource, such as an order ID, but doesn't properly verify that the user making the request has permission to access that resource.

And this doesn't apply only to URLs or orders. The same principle applies whenever an application accesses a protected resource—documents, invoices, messages, projects, files, API resources, or anything else that one user shouldn't automatically be able to access just because they're authenticated.

Authentication establishes who is making the request.

Authorization determines whether that person should be allowed to make it.

3. Input validation

Knowing who sent a request doesn't mean the application can automatically trust what that request contains.

Applications constantly receive information from the outside world.

Form submissions, API requests, URL parameters, uploaded files, headers, and query parameters are all forms of external input.

Input validation establishes what the application considers acceptable before that information is processed.

An email field, for example, can be checked for an expected format. A numeric value can be checked against an acceptable range.

But input validation isn't only about catching accidental mistakes.

Imagine an application expects a numeric product ID:

GET /products?id=123

An attacker could instead send unexpected input containing SQL code. If that input isn't handled safely, it could alter the database query the application executes. This type of attack is known as SQL injection.

💡 What is SQL injection?

SQL injection is an attack where malicious input is used to alter a database query. This can allow an attacker to access, modify, or delete data they shouldn't have access to.

Validating that the product ID is actually a number helps reject unexpected input. At the database layer, parameterized queries provide the primary protection against SQL injection by keeping user input separate from the SQL command itself.

The broader principle is simple: input coming from outside the application shouldn't automatically be trusted.

4. Secrets management

Applications also have sensitive information of their own.

They often need credentials to communicate with databases, APIs, and other services.

These can include:

• API keys

• Database credentials

• Access tokens

• Signing keys

• Third-party service credentials

These values are commonly referred to as secrets.

Secrets are generally kept separate from application code through environment variables or dedicated secrets-management systems.

Hardcoding them into source code creates a different problem: source code tends to be copied, shared, deployed, and stored in version-control systems.

And Git has history.

Removing a secret from the latest version of a file doesn't necessarily remove it from previous commits. This is why a credential accidentally committed to a repository is generally treated as compromised and rotated.

Secrets management is ultimately about controlling where sensitive credentials live and who—or what—can access them.

5. Rate limiting

Even a perfectly valid request can become a problem when it's repeated thousands of times.

That's where rate limiting comes in.

Rate limiting controls how frequently a user, client, or source can perform a particular action within a period of time.

Consider a login endpoint.

A normal user might enter the wrong password a few times.

An automated attacker could potentially try thousands of passwords.

Rate limiting can restrict how many attempts are allowed within a certain period, making this kind of automated abuse more difficult.

The same concept can apply to password resets, verification codes, account creation, API requests, and other operations that could be abused at scale.

Input validation asks:

Is this request acceptable?

Rate limiting asks:

How often should this request be allowed?

They protect against different problems, even though both deal with requests entering an application.

6. Password hashing

Authentication often relies on one particularly sensitive piece of information: a user's password.

Web applications typically don't store users' actual passwords.

Instead, passwords are stored as hashes generated using password-hashing algorithms such as bcrypt or Argon2.

💡 What is hashing?

Hashing is a one-way transformation that takes an input—like a password—and produces a fixed representation called a hash. The same input can be verified against the stored hash later, but the original password isn't meant to be recovered from it.

This is different from encryption, which is designed to be reversible with the right key.

When a user logs in, the password they provide is passed through the same hashing process and checked against the stored password hash. If they match, the password is valid. At no point does the application need to store or recover the original password.

This becomes particularly important if a database is compromised.

If passwords were stored as plain text, anyone with access to the database could immediately read them. With properly hashed passwords, what gets exposed instead are the hashes, making recovering the original passwords significantly more difficult.

7. Dependency vulnerabilities

An application's security doesn't depend only on the code its developers write.

Modern applications rely heavily on third-party code.

Frameworks, database clients, authentication libraries, HTTP clients, and hundreds of smaller packages can become part of an application's dependency tree.

Those dependencies can contain security vulnerabilities too.

When vulnerabilities in third-party packages become publicly known, dependency-scanning tools can help identify whether an application is using an affected version.

💡 What is a CVE?

CVE stands for Common Vulnerabilities and Exposures. A CVE is a standardized identifier assigned to a publicly known security vulnerability, giving everyone a common way to refer to the same vulnerability.

For example, a vulnerability might be identified as CVE-2026-12345.

Dependency-scanning tools can compare the packages and versions used by an application against databases of known vulnerabilities. This makes it possible to identify cases where an application depends on a library version with a documented security problem.

Application security, therefore, isn't limited to the code an engineering team writes. It also includes the code the application depends on.

8. Webhook and callback verification

Applications also communicate with systems outside their own boundaries.

Webhooks are a common example.

Webhooks allow one system to notify another when something happens.

A payment provider might send:

payment.completed

An authentication provider might notify an application about a user event.

A third-party integration might send an update when external data changes.

But a webhook is ultimately an HTTP request.

Simply receiving a request at a particular endpoint doesn't prove that it came from the expected provider.

This is why webhook systems commonly include a mechanism for verifying authenticity, often through cryptographic signatures or shared secrets.

The receiving application can validate that information before trusting the payload.

Without verification, someone who discovers the webhook endpoint could potentially imitate the external service and send fabricated events.

Webhook verification establishes an important boundary of trust: not just what does this request say?, but can the application trust who sent it?

9. Automated security scanning

Many of the problems we've discussed can leave traces that tools are capable of detecting automatically.

Static-analysis tools can inspect source code for potentially dangerous patterns.

Secret scanners can detect credentials that may have accidentally been committed.

Dependency scanners can identify packages associated with known vulnerabilities.

These checks can also be integrated into CI/CD pipelines so they run whenever code changes.

Automation doesn't guarantee that an application is secure, and automated tools can't understand every security implication of an application's design.

What they provide is another layer of detection.

Instead of relying entirely on someone remembering to check for every potential problem, repeatable checks can happen continuously as the software evolves.

10. Backups, logging, and monitoring

Not every security measure is about preventing something from happening.

Some are about understanding what happened and recovering when something goes wrong.

Backups provide a way to recover data after accidental deletion, corruption, infrastructure failure, or certain types of security incidents.

But the existence of a backup doesn't necessarily mean the data is recoverable. Backup strategies also involve verifying that the stored data can actually be restored.

Logging and monitoring address another part of the problem.

Logs can provide information about authentication attempts, application errors, access patterns, and important system events. Monitoring can then help surface unusual behavior or failures that require attention.

At the same time, logs themselves need thoughtful handling. Sensitive information such as passwords, authentication tokens, or secrets generally shouldn't end up there.

The goal isn't simply to prevent every possible incident. It's also to have enough visibility and recoverability to respond when something inevitably goes wrong.

Security is a practice, not a checkbox

Web application security goes much deeper than these ten concepts.

But these fundamentals show how security exists at different layers of an application.

• HTTPS protects information while it travels.

• Authentication establishes identity, while authorization controls access.

• Input validation helps protect the application from unexpected or malicious input.

• Secrets management protects the credentials the application itself depends on.

• Rate limiting helps prevent otherwise valid operations from being abused at scale.

• Password hashing protects users' stored credentials.

• Dependency management extends security considerations to third-party code

• Webhook verification establishes trust with external systems.

• Automated scanning adds another layer of detection.

• And backups, logging, and monitoring help provide visibility and recovery when prevention isn't enough.

Individually, none of these makes an application "secure." Together, they illustrate something important about application security: security isn't usually one feature or one tool. It's a collection of practices applied throughout the lifecycle of a system.

When you first start using Linear, it's easy to think of it primarily as a place to create and track issues.

Create an issue. Assign it. Move it to In Progress. Mark it as Done.

That works well when the scope is small.

But as the work grows, a flat list of issues isn't always enough. Some work belongs to a larger project. Projects have meaningful stages. And sometimes, what looks like a single issue actually requires several steps before it can be considered done.

Linear has a few features that can help you organize all of this without losing sight of the actual work.

A quick note: I'm not affiliated with Linear. I've simply been using it across my last few jobs, including my current one. Along the way, I've been getting more familiar with both Linear and some of the project management concepts behind how work is organized.

Here are four features I've found particularly useful.

1. Projects: Group work around a larger goal

Not every issue should live independently.

Sometimes, a collection of issues contributes to a larger outcome: launching a mobile app, redesigning an onboarding experience, or introducing a new authentication system.

That's where Projects come in.

A project gives related work a shared home and lets you track the larger outcome instead of looking at every issue individually.

For example:

Project: Launch Mobile App

• Build authentication

• Create onboarding experience

• Implement navigation

• Add user settings

• Prepare app for release

Instead of only asking, "Which issues are done?", you can also ask:

"How is the project progressing?"

2. Milestones: Break a project into meaningful stages

A project can still contain dozens—or hundreds—of issues.

Milestones give you another level of organization by breaking the project into meaningful stages.

For our Launch Mobile App project, we could have:

Milestone 1: Authentication

Milestone 2: Core Experience

Milestone 3: Beta Testing

Milestone 4: Public Launch

Issues can then be associated with the milestone they contribute to.

This makes it easier to understand not only how much work remains, but where you are in the journey toward completing the project.

Instead of treating the entire project as one large block of work, milestones give the team smaller targets to work toward.

3. Parent and sub-issues: Break complex issues into actionable work

Sometimes an issue isn't really an issue.

It's a small project hiding inside one.

Imagine creating an issue called:

Implement user authentication

At first, that might sound like a reasonable unit of work.

But then you start thinking about what "done" actually requires:

• Create the login flow

• Implement sign-up

• Add password reset

• Handle session expiration

• Add authentication tests

At that point, keeping everything inside one issue makes it difficult to see what's actually complete and what still needs work.

Instead, you can use the original issue as a parent issue and break the implementation into sub-issues.

The parent captures the larger piece of work.

The sub-issues capture the individual steps required to complete it.

This gives you something similar to an Epic-style structure without needing to turn every multi-step piece of work into its own project.

It's particularly useful when something is too large for one issue but too small to justify creating an entire project around it.

4. Views: Look at the same work from different perspectives

Organizing your work is only part of the problem.

Sometimes you simply need a better way to look at it.

That's where Views become useful.

You can filter your issues and save views based on the information you regularly care about.

For example:

• Issues assigned to me

• Issues currently blocked

• Bugs

• Work ready for development

• High-priority issues

• Issues belonging to a particular project

The underlying issues haven't changed.

You're simply creating different windows into the same work.

This becomes particularly useful as the number of issues grows. Instead of repeatedly searching or applying the same filters, you can create a view for the questions you regularly need to answer.

Different tools for different levels of work

The useful part isn't any individual feature. It's how they work together.

Projects group work around a larger outcome.

Milestones divide that outcome into meaningful stages.

Parent and sub-issues break complex pieces of work into actionable steps.

Views let you look at all that work from the perspective you need.

You don't need all of these for every project.

But as the work gets more complex, having different levels of organization can make it much easier to understand both the bigger picture and what needs to happen next.

Sometimes an issue is enough.

And sometimes you need to zoom out.

This sounds important... and a little scary.

It sounded like one of those engineering terms that everyone else seemed to understand except me.

But once I learned what a backfill actually is, I realized the concept is surprisingly simple.

Let's start with the word itself

If English isn't your first language, the term can sound a bit mysterious.

Outside of software, to backfill simply means:

To fill something in after the fact.

The idea is that something already exists, but there's a gap that needs to be filled later.

For example:

• In construction, workers backfill a trench after installing underground pipes by filling it back in with soil.

  

• In human resources, companies backfill a position when they hire someone to replace an employee who left.

Different contexts, same idea.

You're going back to fill something that wasn't filled before.

Software engineering borrowed exactly that idea.

So... what is a backfill in software?

A backfill is the process of updating historical data so it conforms to the current version of your data model.

Or, put another way:

It makes old data look as if today's data model had always existed.

I find this to be the simplest way to think about backfills.

Why do we need them?

Data models evolve.

No matter how carefully you design your database, requirements change.

You might:

• split one field into several

• introduce a new table

• rename a column

• change how information is represented

• move data to a different storage system

• remove fields that are no longer needed

Updating the application code is only half the job. The application now understands the new model. Your existing data doesn't.

Do backfills only happen after a data model change?

No. While data model evolution is the most common reason to perform a backfill, it's not the only one.

Teams also perform backfills when importing older historical records that weren't previously available. For example, you might initially load one year of transaction history and later decide to import the previous five years.

In both cases, you're filling historical gaps—just for different reasons.

A practical example

Imagine your application has been storing customer addresses like this for years:

address = "123 Main St, New York, NY"

Eventually, the business wants to search customers by city and state.

So the model evolves into:

street
city
state

Every new customer is stored using the new structure.

But what about the millions of customers that already exist?

Their data doesn't magically reorganize itself.

A backfill reads those historical records, extracts each component, and populates the new fields so both old and new records follow the same model.

Once the backfill is complete, every customer record follows the same structure, regardless of when it was created.

Is a backfill the same as a data migration?

Not exactly.

The terms are closely related and are often used interchangeably, but I find it helpful to think about them in terms of their goal.

A data migration typically moves or restructures data.

A backfill updates historical data so it matches the current version of your model.

Many migrations include a backfill as one of their steps, but not every backfill is part of a migration.

Sometimes you're doing both at the same time.

Why production backfills sound intimidating

When someone says:

"We need to build a backfill."

it's easy to imagine some mysterious, high-risk engineering task.

In reality, the concept itself is straightforward.

You're simply updating historical data because your understanding of the domain has evolved.

Of course, executing a production backfill safely is another story.

Large datasets often require batching, monitoring, idempotency, retry mechanisms, and careful planning to avoid impacting users.

Those challenges are real.

But they're challenges of execution—not of the concept itself.

Final thoughts

Software systems evolve. Data evolves with them. Whether that means adapting historical records to a new data model, enriching existing data, or filling in historical gaps, backfills are simply the mechanism that allows historical data to catch up.

Viewed through this lens, a backfill isn't an unusual operation—it's a natural part of building evolving software systems.

But when I started building my own side project, I wasn't solving an enterprise problem anymore. My goal wasn't to support millions of users—it was to validate an idea, ship quickly, and keep costs low while I figured out whether anyone actually wanted to use it.

That shift in priorities reinforced something I'd long believed:

The right technology stack isn't universal. It depends on the stage of your project and the constraints you're working within.

Building my own side project gave me the opportunity to put that idea into practice in a very different context.

Here are some of the lessons I learned along the way.

Choose the Framework That Helps You Ship

One of the biggest decisions you'll make is choosing the technology you'll build with.

At work, I spend a lot of time with technologies commonly used in enterprise environments, like Java. My first instinct was to build my project using what I already knew best.

But then I stopped and asked myself what I was actually trying to accomplish.

My goal wasn't to build a system capable of serving thousands of concurrent users. It was to get an idea in front of users as quickly as possible.

That's why I chose Ruby on Rails.

Was I already proficient with it?

No.

But AI coding assistants made the learning curve much less intimidating. They helped me understand Rails conventions while applying concepts I already knew from years of software engineering.

Choosing a framework optimized for developer productivity helped me move much faster than optimizing for theoretical scalability.

Build Infrastructure for Today's Scale

The next lesson was realizing that my infrastructure should reflect the scale of my project—not the scale of the systems I build professionally.

Don't Pay for Idle Compute

Most side projects spend the majority of their time waiting for the next user.

That's what makes a serverless database such a great fit.

Instead of paying for compute that's running 24/7, I chose Neon. Since compute only runs when the database is actually being used, costs stay incredibly low while the application is idle.

I also liked knowing that even if my project eventually outgrew the free tier, I wasn't going to be hit with a huge jump in costs. The pricing remains incredibly affordable, making it easy to grow without constantly worrying about the next bill.

Deploy Without the Complexity

Once your application is working locally, the next challenge is getting it online so other people can actually use it.

For my side project, I wasn't looking for a hosting platform with every possible feature or endless configuration options. I wanted something affordable that would let me deploy a container, share the application with users, and get back to building features.

Given those constraints, Fly.io turned out to be a great fit for my side project.

One of the things I liked most was how easy it was to deploy a container and immediately have a publicly accessible HTTPS application. TLS certificates are managed automatically, so I didn't have to configure or maintain them myself.

Another benefit was that I didn't even need to buy a domain name to get started. Fly.io provides a public HTTPS URL out of the box, making it easy to deploy and share an application while you're still validating an idea.

Once I was ready for a more polished experience, I purchased an inexpensive domain through Namecheap and pointed it to my application. I also set up a professional email address with Zoho Mail. Neither cost much, but together they made the project feel much more established when communicating with users.

In the end, hosting became something I could set up once and largely forget about, leaving me free to focus on improving the product instead of managing infrastructure.

Keep Async Processing Simple

As your application grows, you'll eventually need work to happen outside the request-response cycle. That might be sending emails, generating reports, processing uploads, or running scheduled tasks.

My application only had one background task: sending payment reminders once a day.

My first instinct was to spin up a dedicated worker for asynchronous processing. It worked, but I quickly realized I had created another always-on service that continuously interacted with my serverless database. That meant I wasn't just paying for the worker itself—I was also causing my database to wake up more frequently, increasing my overall costs.

That's when I stopped and asked myself:

Do I really need another server for this?

In my case, the answer was no.

Since I only needed a scheduled job once a day, GitHub Actions turned out to be a surprisingly good fit.

Are scheduled workflows guaranteed to run at the exact minute you specify?

No.

But if a reminder goes out at 9:18 AM instead of exactly 9:00 AM, that's perfectly acceptable for my use case.

GitHub Actions happened to be the solution I chose, but many hosting providers also offer scheduled jobs or cron-like functionality that can accomplish the same thing without introducing another always-on service.

The lesson for me was simple: not every background task needs a dedicated worker. Sometimes a scheduler is all you need.

Invest Early in Visibility

Once other people start using your application, you'll eventually face a simple question:

How will you know when something breaks?

I didn't want to rely on users to report problems before I knew about them. Even though my project was small, I wanted the same level of visibility I value when working on enterprise systems.

That's why I chose Sentry.

What surprised me wasn't the tool itself—it was the scale.

In large production systems, it's not unusual to receive hundreds of error notifications in a single day. With my side project, I might only see a handful of errors in an entire month.

At that scale, Sentry's free tier was more than enough, and the visibility it provided was invaluable. The first time an unexpected error appeared, I knew about it immediately instead of hearing about it from a user.

Error monitoring was one of those enterprise practices that turned out to be surprisingly affordable at a small scale—and one I would absolutely adopt again from day one.

Spend Money Where It Solves a Real Problem

Building on a budget doesn't necessarily mean spending nothing. It means being intentional about what you pay for.

For me, AI coding assistants fell into that category.

If you're only working on your project a few hours each week, even an entry-level paid plan can save hours of debugging, boilerplate code, and research.

I'd rather spend a small amount on a tool that helps me move faster than let the limitations of a free plan slow me down.

Unlike infrastructure, your time doesn't have a generous free tier.

Final Thoughts

Looking back, every decision came down to asking the same question:

What problem am I actually solving today?

That simple question shaped every technical decision I made:

• Choose the framework that helps you ship.
• Build infrastructure for today's scale.
• Don't pay for idle compute.
• Deploy without the complexity.
• Keep async processing simple.
• Invest early in visibility.
• Spend money where it solves a real problem.

None of these lessons are tied to a specific technology. They're about matching your engineering decisions to the problem you're actually trying to solve.

Working on enterprise systems can easily shape how we think software should be built. But side projects play by different rules. The goal is to build something useful, learn from real users, and evolve the system as it grows.

In addition, The right technology stack isn't universal. It depends on the stage of your project and the constraints you're working within. If your project eventually needs enterprise infrastructure, that's a wonderful problem to have.It means you've built something people actually want to use.

I'm curious to hear from others who have built side projects.

What lessons have you learned about choosing technologies under different constraints? Is there a tool, service, or engineering decision that worked particularly well for you?

Any system that processes a stream of messages—orders, events, uploads, whatever—will eventually hit one it can’t handle. Maybe the message is malformed. Maybe a downstream dependency is unavailable. Maybe there’s a bug nobody’s noticed yet.

Without a plan for this, you typically end up with one of two outcomes: the application processing the messages crashes and stops processing everything behind the bad message, or it catches the exception, logs the failure, and moves on—quietly ignoring the failed message and potentially losing data in the process.

The first outcome is rarely acceptable. The second is often where many of us start. Logging the exception is a good first step—it tells you something went wrong. But what if you fix the bug tomorrow? Those messages might now process just fine, yet they’re already gone.

That’s where a Dead Letter Queue (DLQ) comes in.

The pattern

A Dead Letter Queue gives failed messages a third option: park them somewhere durable, log why they failed, and keep going.

Why is it called a Dead Letter Queue?

The name comes from the postal service. A dead letter was mail that couldn’t be delivered to its intended recipient and was instead sent to a Dead Letter Office for investigation or manual handling.

A Dead Letter Queue follows the same idea: messages that can’t be processed are moved aside instead of being discarded, giving someone—or something—a chance to inspect and recover them later.

The application processing the messages isn’t blocked, no message is silently discarded, and there’s a record of exactly what went wrong and when.

Mechanically, it’s simple. Catch the failure, write a copy of the message (along with the error and any useful context) to storage—a dedicated queue, topic, or, in many real systems, just a database table or collection—and acknowledge the original message so the pipeline can move on to the next one.

A simple mental model is:

Things fail → retry if appropriate → if we still can’t process the message, move it to the Dead Letter Queue.

The trap

Here’s the part that doesn’t make it into most tutorials: writing to a DLQ is the easy half. The hard half—and the one that gets skipped surprisingly often—is having something that actually reads it back.

It’s an easy gap to fall into because the write side feels like “handling” the error. The code catches the exception, logs it, stores it somewhere durable—it looks resolved. But unless something is actively reading from that DLQ, replaying messages, and clearing the ones that succeed, it’s not a safety net. It’s a write-only log of things nobody’s coming back for.

The failures stop crashing the system, but they also stop getting fixed—they just accumulate until someone happens to go looking.

I once came across a production issue where one type of message kept failing during processing. The application stayed healthy because every failed message was successfully written to the DLQ. Everything appeared healthy. Yet, by the time someone checked, thousands of messages had quietly accumulated.

The DLQ had done exactly what it was designed to do—but nobody was looking at it.

What makes a DLQ actually work

A few things separate a DLQ that’s a genuine safety net from one that’s simply a collection of forgotten messages.

1. A replay path

Have a way to process failed messages again.

That might be a script, a scheduled job, an admin endpoint, or even a documented manual process. The important thing is that replay exists before you need it.

1. Idempotent processing

Replay only works safely if processing the same message twice doesn’t create duplicate side effects.

Design your processing with this in mind from the beginning—whether that’s using upserts, delete-and-recreate strategies, or another idempotent approach.

1. Visibility

Don’t just monitor whether the DLQ exists. Monitor its size and, even more importantly, whether it’s growing.

A DLQ with a handful of messages may not be a problem. One that’s quietly growing every day almost certainly is.

1. Enough context to debug

Saving the exception alone is a good start, but it often isn’t enough.

Store the information you’ll actually need later to understand the failure: identifiers, timestamps, retry count, or whatever helps explain why the message ended up there in the first place.

The takeaway

A DLQ is only half of the mechanism, and the write side is the easy half.

If you’re adding one to a system, the question worth asking isn’t “Where do failed messages go?”

It’s “Who, or what, brings them back?”

Because a Dead Letter Queue isn’t just a place to store failed messages.

It’s an operational workflow.

Without replay, visibility, and ownership, you’ve simply built a very reliable place for problems to wait until someone accidentally discovers them.

Say you have a GitHub Actions workflow that someone can manually trigger to deploy something to an environment. It could be production, staging, preproduction, or any other environment where you want to control who can perform the deployment.

For this example, we'll use production.

You want to make sure that only certain people can deploy to it.

There are two ways you might approach this.

Option 1: Check the actor in the workflow

One simple solution is to keep a list of allowed users directly in the workflow and check who triggered it:

env:
  ALLOWED_ACTORS: "alice bob"

jobs:
  check-actor:
    runs-on: ubuntu-latest
    steps:
      - name: Verify actor
        env:
          ACTOR: ${{ github.actor }}
        run: |
          for a in $ALLOWED_ACTORS; do
            if [[ "$ACTOR" == "$a" ]]; then
              exit 0
            fi
          done
          echo "::error::Actor '$ACTOR' is not allowed."
          exit 1

  deploy:
    needs: check-actor
    steps: [...]

This is simple and it works. If the person who triggered the workflow is on the list, the deployment continues. Otherwise, it fails.

But there are some downsides.

First, the list of allowed users is hardcoded. If someone else needs permission to deploy, you have to modify the workflow file and merge that change.

More importantly, the protection itself lives inside the workflow. Anyone with permission to modify that file could potentially add themselves to the list, change the check, or remove it entirely.

For a sensitive operation like deploying to production, that's an important limitation.

Option 2: Use GitHub environments

GitHub provides a built-in way to protect deployments through environments.

Instead of implementing the access check yourself, your deployment job can target a configured environment:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps: [...]

The production environment is configured in the repository settings.

To configure it:

1. Go to your repository on GitHub.

2. Open Settings → Environments.

3. Create or select the production environment.

4. Under Deployment protection rules, enable Required reviewers.

5. Add the users or teams authorized to approve deployments.

6. Optionally, enable Prevent self-review if you want to require someone other than the person who triggered the workflow to approve the deployment.

Once configured, when the workflow reaches a job that targets the production environment, GitHub pauses the job and waits for approval from an authorized reviewer before continuing.

The same approach can be used for other environments. For example, you could have separate staging, preproduction, and production environments, each with its own protection rules and authorized reviewers.

This keeps the list of authorized reviewers out of the workflow and gives you built-in deployment history and traceability without having to build your own auditing mechanism.

Where to see your deployment history

Once you start using GitHub environments, GitHub keeps a record of your deployments.

You can find this history from your repository's main page, under Deployments. From there, you can see deployments to each environment and inspect details such as who triggered the deployment, which branch or commit was deployed, when it happened, whether it succeeded or failed, and who approved it when approval was required.

This gives you a built-in audit trail without having to create or maintain one yourself.

GitHub provides more details on how to view deployment history.

Conclusion

Both approaches can restrict who is allowed to deploy, but for sensitive environments like production, GitHub environments provide better protection and built-in traceability without requiring custom logic in your workflow.

It isn't.

A webhook is simply an HTTP endpoint on your server that another system calls to notify you when something happens.

A simple way to think about it is as a phone number.

Imagine you give someone your phone number.

Whenever they have something to tell you, they call you.

A webhook works the same way.

Phone number      → Webhook URL
Phone call        → HTTP POST request
Caller ID         → Signature verification
"Got it."         → HTTP 200 OK

When an Event Happens

Suppose you're integrating with a payment provider.

When a payment succeeds, they send an HTTP POST request to your webhook endpoint.

Your application receives the request, processes it, and returns 200 OK.

A simplified flow looks like this:

Payment succeeds
        │
        ▼
 Payment Provider
        │
 POST /webhook
        │
        ▼
 Your Application
        │
 Process event
        │
 Return 200 OK

Setting Up a Webhook

Before any events start flowing, there's usually a one-time setup.

First, you expose an HTTP endpoint in your application that will receive incoming events.

For example:

POST /webhook

You then provide that URL to the other system so it knows where to send events.

The sender also gives you a shared secret.

Your application uses that secret to verify that incoming requests really came from them before processing the event.

A typical webhook handler follows this flow:

Webhook arrives
        │
        ▼
Verify signature
        │
        ▼
Queue or store the work
        │
        ▼
Return 200 OK
        │
        ▼
Background worker

Notice that the handler itself stays lightweight.

Its responsibility is to acknowledge the event quickly. Any heavier processing—sending emails, updating databases, or calling other services—can happen afterward in a background worker.

Why Use Webhooks?

Without webhooks, your application has to keep asking another system if anything has changed.

This is commonly called polling.

With webhooks, the opposite happens.

The other system notifies you only when there's something new to report.

Here's a quick comparison:

Wrapping Up

A webhook is simply an HTTP endpoint on your server that another system calls to notify you when something happens.

The technology underneath is the same HTTP you've probably been using for years.

The only thing that changes is who starts the conversation.

This time, let's look at a specific use case: building a customer-facing MCP server.

If your goal is to allow customers to interact with your product through AI clients such as Claude, ChatGPT, Cursor, or Claude Code, what do you actually need?

The good news is that if you already have APIs or services, you're often closer than you think.

The Essentials

If you're building a first version, I'd focus on these first.

1. Existing Functionality to Expose

Most MCP servers sit on top of functionality that already exists.

That functionality might come from:

• REST APIs

• GraphQL APIs

• Databases

• Internal services

The MCP server becomes a layer that exposes that functionality to AI agents.

One thing you'll quickly discover is that not every API endpoint necessarily deserves to become a tool.

The goal isn't to mirror your API one-to-one. Instead, think in terms of capabilities that would be useful to an AI assistant.

For example, instead of exposing:

GET /projects
GET /projects/{id}
POST /projects/{id}/tickets

You might expose higher-level tools such as:

search_projects
create_ticket

The MCP server can orchestrate one or multiple API calls behind the scenes. What matters is not how your API is structured internally, but what actions are useful for the AI assistant to expose to the user.

One thing that surprised me was how capable modern AI clients are once they have access to well-defined tools.

My initial instinct was to think through every possible workflow a user might need. In practice, I found that the AI client could often orchestrate much of that on its own.

For example, imagine an MCP server exposes:

• search_projects

• create_ticket

• get_ticket_status

A user might ask:

Create a ticket for the login issue in the Mobile App project and let me know when it's done.

The AI client can determine which tools to invoke, chain multiple calls together, provide the appropriate inputs, and even check back for updates if the workflow requires it.

This changed how I thought about tool design. Rather than exposing a tool for every workflow, I found it more useful to expose clear capabilities with good names and descriptions, allowing the AI client to orchestrate them as needed.

2. An MCP SDK

The easiest way to get started is with an MCP SDK.

SDKs are available for several languages, including:

• TypeScript

• Python

• Java

The SDK handles much of the underlying protocol and transport details, allowing you to focus on defining the tools, resources, and prompts you want to expose.

3. Choose a Transport

One of the first architectural decisions is how clients will communicate with your MCP server.

The two most common options are:

• stdio

• HTTP

For my first implementation, I started with stdio.

It was a great way to get a prototype working quickly and test the integration in my local development environment. Since the MCP client launches the server as a local process, getting started was relatively straightforward.

Within a short time, I had my existing APIs connected to Claude and was able to interact with them conversationally. Instead of manually calling endpoints or testing requests, I could simply ask Claude to perform actions using the tools exposed by my MCP server.

It didn't take long, however, to realize that our end goal wasn't a local integration—it was allowing multiple customers to connect to the same MCP server. At that point, an HTTP-based server became the more appropriate choice.

If your goal is simply to get a feel for MCP and validate an integration quickly, starting with stdio can be a good option. It lets you connect your APIs to an AI client with minimal setup and experiment locally.

However, if you already know you'll need a hosted, multi-user solution, you may prefer to go straight to an HTTP-based server.

4. Decide What to Expose

One of the most important design decisions is deciding what functionality should be available to AI agents.

A common mistake is trying to expose everything.

For a first version, focus on the handful of actions that provide the most value.

Ask yourself:

If a customer connected this MCP server today, what are the top five things they would want an AI assistant to do?

Start there.

You can always expose additional functionality later.

5. Decide How Users Will Authenticate

If your MCP server exposes customer data or performs actions on behalf of users, you'll need a way to authenticate them.

Authentication becomes especially important once multiple customers start connecting to the same MCP server.

The AI assistant isn't acting on its own behalf—it is acting on behalf of a specific user.

That means the MCP server needs a way to identify who the user is and what data they are allowed to access.

Common approaches include:

• API Keys

• OAuth

We'll explore authentication in more detail in a future article.

Start With the Smallest Useful Integration

One thing I found useful was focusing on getting a single end-to-end workflow working first.

For example:

1. Connect an MCP client to the server.

2. Authenticate a user.

3. Expose a small set of useful tools.

4. Successfully invoke those tools from the AI assistant.

Once that foundation is working, it's much easier to iterate.

You can always add more tools, resources, prompts, richer authentication flows, and additional transports later.

In my experience, the challenge isn't usually exposing another tool. It's making sure the entire flow works smoothly—from connecting the client, to authenticating the user, to successfully invoking functionality in your application.

Nice-to-Haves That Improve the Experience

Once you have a working integration, there are several things that can make your MCP server even more effective.

6. Provide Context

One thing I didn't fully appreciate at first is that exposing tools is only part of the solution.

The AI also needs context to understand how those tools should be used.

For example, in one implementation, the underlying application stored dates and times in a specific timezone, while users interacted with the AI in their own local timezone.

Providing that context allowed the AI to perform the appropriate conversions before invoking tools or presenting results.

I found this particularly powerful because it allowed the AI to adapt its behavior without requiring additional tools or changes to the underlying APIs to accommodate every possible use case.

In many cases, if the AI seems to be making poor decisions, the missing piece isn't another capability—it's additional context.

7. Consider Resources and Prompts

Many MCP servers start with tools, but the protocol also supports resources and prompts.

Resources can provide additional context, such as product documentation, while prompts can expose reusable instructions or workflows.

These aren't always necessary for a first version, but they can be valuable additions as your MCP server evolves.

8. Document How to Use It

Even with a standardized protocol, documentation still matters.

Users need to know:

• What your MCP server does

• How to install it

• How to authenticate

• Which AI tools support it

Good documentation often makes the difference between an MCP server that gets adopted and one that doesn't.

Conclusion

One thing I learned is that a lot of MCP server design decisions become clearer through testing and real usage.

As you try different scenarios, you'll quickly discover whether:

• The agent is missing important context.

• A tool is missing.

• Two tools should be combined.

• A description needs to be clearer.

• Additional resources would help.

I was also surprised by how capable modern AI clients are once they have access to well-defined tools. They can often chain multiple calls together, provide the appropriate inputs, and orchestrate workflows that I initially thought would require dedicated tools.

The best way to understand what your MCP server needs isn't to design every possible workflow upfront—it's to start with a small but useful integration and observe how the AI client uses it in practice.

Over time, those interactions will tell you where the gaps are and how the server should evolve.

But what actually happens when an AI assistant uses an MCP server?

You don't need to understand every detail of the protocol to understand MCP. A simple mental model is enough.

The Big Picture

MCP Client (Claude, Cursor, ChatGPT, etc.)
                    │
                    ▼
               MCP Server
                    │
                    ▼
              Your Application

The MCP client is usually an AI application such as Claude, Cursor, ChatGPT, or Claude Code.

The MCP server sits between the AI assistant and your application. Its job is to expose information and functionality that the AI can discover and use.

You can think of it as another layer of abstraction between the AI client and your application's underlying APIs or services.

Claude
   │
   ▼
MCP Server
   │
   ▼
Your APIs / Services

But where does the MCP server come from?

Someone has to build it.

In many cases, the company behind the product provides an official MCP server. For example, GitHub, Linear, and other companies now offer MCP servers that expose functionality from their platforms to AI assistants.

If your company wants AI agents to interact with its products, your team would typically build and host an MCP server that AI clients can connect to.

Much like a REST API allows developers to interact with your application, an MCP server allows AI agents to interact with it.

What Does an MCP Server Expose?

At a high level, an MCP server can expose three types of things:

MCP Server
│
├── Tools
├── Resources
└── Prompts

Tools

Tools are actions the AI can perform.

Examples:

create_ticket
search_issues
send_message

When you ask Claude to create a Linear ticket, it is typically invoking a tool exposed by the Linear MCP server.

Resources

Resources are information the AI can read and use as context.

For example, imagine your company exposes its product documentation as a resource. An AI assistant could retrieve that documentation to answer questions or better understand how to use your product before invoking any tools.

A simple way to think about it:

• Tools → the AI wants to do something

• Resources → the AI wants to know something

Prompts

Prompts are reusable instructions exposed by the MCP server.

For example, a company might provide prompts such as:

• Summarize a project

• Review code changes

• Explain an error message

Rather than requiring every client to define these instructions, they can be exposed directly by the MCP server.

A simple way to think about it:

• Tools → the AI wants to do something

• Resources → the AI wants to know something

• Prompts → the AI wants guidance on how to do it

How Does the AI Know What's Available?

Before an AI assistant can use a tool, it first needs to discover what the MCP server provides.

A simplified version of that conversation looks like this:

Client
  │
  ├── initialize
  │
  ├── tools/list
  │
  ├── resources/list
  │
  └── prompts/list

Think of it as the AI asking:

What can you do?

The server responds with the tools, resources, and prompts it makes available.

How Do Clients and Servers Communicate?

All interactions between an MCP client and an MCP server happen through messages.

MCP standardizes these interactions using JSON-RPC, a lightweight protocol for request and response communication.

Those messages travel through a transport layer. MCP supports transports such as stdio and HTTP, which determine how the client and server communicate with each other.

Most developers interact with MCP through SDKs, which handle much of the underlying protocol and transport details for you. This allows developers to focus on the functionality they want to expose rather than the mechanics of the protocol itself.

What Happens When a Tool Is Used?

Let's say you ask Claude:

Create a Linear ticket for a login bug.

The flow looks something like this:

User
 │
 ▼
"Create a Linear ticket"
 │
 ▼
Claude
 │
 ▼
tools/call(create_ticket)
 │
 ▼
Linear MCP Server
 │
 ▼
Linear

Claude invokes the appropriate tool, the MCP server performs the operation, and the result is returned back to Claude.

Bringing It All Together

           MCP Client
      (Claude, Cursor, etc.)
                   │
                   ▼
             MCP Server
        ┌──────┼──────┐
        ▼      ▼      ▼
      Tools Resources Prompts
                   │
                   ▼
      APIs / Databases / Services

The client discovers what the server exposes and uses tools, resources, or prompts as needed.

That's the core mental model behind MCP.

In the next article, we'll look at what you actually need to build your own MCP server.

After shipping the first version, I started noticing MCP everywhere. GitHub has one. Linear has one. Slack, Notion, databases, browser automation tools—the list keeps growing. It seems like every week another company is making their functionalities available through MCP.

So what exactly is MCP?

What Is MCP?

MCP (Model Context Protocol) is a lightweight standard that allows AI agents to discover and use the actions an application makes available, such as creating a ticket, searching for issues, retrieving customer data, or updating a record.

Many companies already expose this functionality —often referred to as capabilities— through REST or GraphQL APIs. The challenge is not that the functionality doesn't exist—it's that every API exposes it differently. MCP provides a standard way for AI agents to discover what's available, understand how to invoke it, and interact with it consistently.

REST APIs are typically designed for developers. MCP servers are designed for AI agents.

How Does It Work?

A typical setup looks something like this:

AI Assistant
      ↓
  MCP Server
      ↓
 REST / GraphQL API
      ↓
 Application

The MCP server exposes information and functionality that the AI assistant can discover and use.

When a user asks the assistant to perform an action or retrieve information, the assistant can interact with the underlying application through the MCP server.

MCP Usage in Practice

Many popular products now provide official MCP integrations, including:

• GitHub

• Linear

• Slack

• Notion

• Stripe

• Browser automation tools

Let's look at a concrete example using the Linear MCP with Claude Code.

Step 1: Install the Linear MCP

claude mcp add linear

Or simply ask Claude:

Install the Linear MCP for me.

Claude will guide you through the installation and authentication process.

Step 2: Use It

Once connected, you can ask things like:

View your open issues

What are my open Linear issues?

Create a ticket

Create a high-priority bug ticket for users being logged out unexpectedly.

Search sprint work

Show me all issues assigned to me this sprint.

From the user's perspective, it feels like a conversation.

For example, when you ask Claude to create a Linear ticket, Claude sends the request to the Linear MCP server. The MCP server exposes actions such as creating tickets or searching issues and knows how to translate those requests into operations in Linear.

##If AI agents can already use APIs, why do we need MCP?

AI agents can interact with REST and GraphQL APIs directly, so MCP isn't solving a technical limitation.

The value of MCP is that it gives AI agents a predictable way to discover what an application can do and how to use it.

For example, an AI assistant could be connected to GitHub, Linear, Slack, and dozens of other tools. Without a common standard, each integration would expose its functionality differently. MCP provides a consistent way for AI agents to discover available actions and interact with those systems.

Why Developers Should Care

MCP is quickly becoming one of the standard ways companies expose their products to AI agents. If your company provides APIs, there's a good chance you'll encounter MCP as organizations look for ways to make their products accessible to AI-powered tools and workflows.

Even if you're not building MCP servers yourself, you can benefit from the growing ecosystem of MCP integrations. By connecting AI assistants to tools you already use—such as GitHub, Linear, Slack, or Notion—you can automate repetitive tasks, retrieve information more easily, and streamline everyday workflows.

Whether you're building products or simply using them, MCP is becoming an increasingly important part of how AI systems interact with software.

I was working on a feature when we realized there was a bug fix that needed to happen first because it was a prerequisite.

And that’s when worktrees clicked for me.

So… what is a Git worktree?

A Git worktree lets you have multiple working directories of the same repository on your computer, each checked out to a different branch.

Instead of constantly switching branches in one folder, you can have something like this:

/my-app-main
/my-app-feature
/my-app-bugfix

All connected to the same Git repository — but each on a different branch.

Without worktrees

Imagine you’re halfway through building a feature:

git checkout feature/new-reporting

Then you realize a bug fix must happen first because it’s blocking the feature.

Normally, the flow might look something like this:

git stash
git checkout main
git pull
git checkout -b fix/auth-token

Fix the bug, push it, merge it… then come back:

git checkout feature/new-reporting
git stash pop

Totally workable.

But there’s friction.

You interrupt your flow, mentally bookmark where you were, and juggle branch switching, stashes, and working state.

With worktrees

Instead, you can keep your feature exactly where it is and create a separate working directory for the bug fix.

From your repo:

git worktree add ../my-app-bugfix -b fix/auth-token main

Now you have:

/my-app-feature   → feature/new-reporting
/my-app-bugfix    → fix/auth-token

You can literally open both folders side by side.

Your feature stays untouched while you work on the prerequisite bug fix. When the fix is merged, you can update your feature branch and continue.

You’re still context switching.

But it feels much more graceful.

Especially with coding assistants, I’ve found this surprisingly helpful.

It makes parallel threads of work feel much more natural.

For example, I might be actively building a feature in one worktree while a separate Claude session works on a prerequisite bug fix in another — all within the same repository, but isolated from each other.

Or I might spin up a temporary worktree for an experiment without disrupting the work already in progress.

You’re still coordinating and context switching, but the friction feels much lower.

A small practice that seems helpful

It could be helfpul s keep a default worktree always synced with main, something like:

/my-app-main      → always synced with main
/my-app-feature   → current feature
/my-app-hotfix    → urgent fix

That way, creating new branches or experiments feels lightweight and you always have a clean starting point.

It’s one of those Git features I wish I had tried earlier.

Sharing in case it’s useful for someone else too.

Claude Code has quickly become one of the go-to coding assistants for many developers and teams. I’ve been using it as part of my day-to-day workflow, and over time I’ve noticed that it hasn’t just changed how I code, but also how I approach building software.

This is not meant to be a set of best practices or anything definitive—just a collection of things that have genuinely helped me so far, in case they’re useful to someone else as well.

I’ve found my way of working with it gradually shifting:

• from using it for isolated tasks

• to being more intentional about planning and context

• to using it for refinement and quality improvements

• and finally toward thinking more automation-first in general

1. Getting comfortable with sessions and keeping context

One of the first things that made a difference for me was just getting comfortable with how sessions work, and how to recover or continue work without losing context.

/login helps you recover without losing context

If you ever need to switch accounts or your session expires, you can use:

/login

This lets you reauthenticate without losing your current context.

Useful when:

• switching subscriptions or accounts

• dealing with expired sessions

• recovering access without restarting your work

Small thing, but I’ve found it helps maintain flow.

claude --resume is a safety net (with one catch)

Another thing that has been really helpful is being able to resume sessions.

You can use:

claude --resume

to return to a previous session.

This has been especially useful when things go wrong:

• accidental terminal closes

• machine restarts

• terminal freezes (this has happened to me more than a handful of times)

It’s also useful when working on different things and wanting to keep contexts separated across sessions.

One thing I didn’t realize at first:

--resume is scoped per directory.

If you’re not in the same directory where you started the session, you won’t see it. I learned this empirically after thinking I had lost everything—when I was just in the wrong folder.

/btw helps you keep momentum

More recently, I’ve also found /btw useful.

It lets you ask questions or leave comments without interrupting the current work.

Instead of breaking the flow of a task, you can surface clarifications while the assistant continues working.

It’s a small thing, but it helps keep iteration smooth.

There are many other commands and I haven’t explored most of them yet, but I’m curious to keep discovering more over time.

2. Learning to guide the assistant better

Plan before implementing

I’ve found it works much better to align on a plan before jumping into implementation.

Before coding, I usually ask Claude to outline:

• the approach

• the scope

• the main steps

This tends to lead to more predictable outcomes and fewer surprises later.

Otherwise, you risk getting code that technically works but doesn’t match how you actually wanted things to be structured or behave.

Provide the right context, not more context

Coding assistants have gotten really good—but the outcome is still very tied to the input.

When it makes sense, I try to include things like:

• ticket context (title + description)

• PRDs or specs

• related PRs or discussions

• incident reports

• logs or traces

• specific files or references

The goal is to help build the right context around the problem.

That said, this is very dependent on what you’re building. For simpler tasks, you don’t need much input to get a correct implementation.

But as things get more complex, the difference becomes obvious.

It’s not about adding more input—it’s about adding the right input.

I like to think of it as getting an incident report with no repro steps or logs—you’d be lost. And the same applies to the agent.

Challenge limitations instead of accepting them

Sometimes the agent will say it can’t do something and suggest doing it manually in another terminal.

In those cases, I don’t always take that at face value.

There have been situations where:

• it actually can do it within the current context

• it has done similar things before

• or the limitation isn’t entirely clear

So instead, I try to push a bit:

• “Can you try doing this directly?”

• “What exactly is preventing you from doing it here?”

Not in a forceful way, but just to better understand what’s going on and avoid unnecessary manual work when possible.

Use Claude for refinement, not just implementation

Another part of how I use Claude is not just to build things, but to refine and improve them.

This can include:

• system architecture

• code structure and conventions

• testing strategy

• performance considerations

• maintainability and scalability

• security and documentation

These are all things I used to think through more manually, and now I find it helpful to involve the agent in that process as well.

It doesn’t replace thinking, but it helps get to a more polished result faster.

Preferences help, but don’t always persist

Another thing I do is ask the agent to keep certain preferences in mind.

This might include:

• coding style

• architectural choices

• naming conventions

• testing expectations

It can help reduce repetition and keep things more aligned with how I like to work.

That said, it’s not perfect. It doesn’t always remember or apply these consistently across sessions, so I do find myself repeating things.

I do think this is an area where things can improve, and I’m curious to explore better ways of handling this over time.

3. Shifting toward automation-first thinking

One of the bigger shifts for me has been moving away from doing things manually by default.

Now I tend to delegate a lot of repetitive or operational work to the assistant:

• creating feature branches

• opening pull requests

• drafting documents

• running repetitive git tasks

• setting up GitHub workflows

And more generally, it’s changed how I think about work.

Now when I see something manual, my first thought is:

can this be automated?

Sometimes that leads to:

• writing a small shell script

• creating aliases

• setting environment variables

• or adding a GitHub workflow to handle it

Individually these are small improvements, but over time they reduce a lot of friction.

4. Using different tools depending on the stage of work

Another thing I do sometimes is use non-coding agents, like ChatGPT, for earlier stages of thinking before switching to Claude for implementation.

This has been especially useful for:

• brainstorming ideas

• light planning

• product and UX thinking

• system architecture design

Not all work starts with code. Some of it benefits from a more open-ended space before getting into implementation details.

Once things feel clearer, I then move into Claude to actually build, refine, and execute.

It’s a simple separation, but I’ve found it helps me keep better structure between:

• thinking and shaping the problem

• and actually building the solution

Final thoughts

These are just some of the things that have helped me so far while working with Claude.

What stands out most to me is that this is still evolving. The more I use it, the more I notice small adjustments in how I think about building, structuring, and automating work.

Some of these things I’ve learned through trial and error, and others have come more naturally as I’ve kept incorporating AI into my day-to-day workflow.

I’m sure this will continue to evolve over time—and I’d be curious to hear how others are approaching it as well.

It’s just me, an idea, and the responsibility of turning it into something real.

At first, I assumed the challenge would be execution: writing code and building features quickly.

But I’ve realized something more subtle:

The hardest part is not building the feature — it’s deciding what to build, and how small that version needs to be to validate real user behavior.

This is just one of several challenges I’m starting to recognize, and I suspect there are more worth writing about as I keep building.

How I’ve Always Thought About Features

I’ve always approached features with a consistent mental model.

Whenever I work on something, I naturally think about:

• why it exists and what value it creates

• what problem it solves

• how it can be simplified

• what edge cases matter

• what I explicitly don’t want to build

• how it fits into the existing data model and UI

• how the user experience should feel end-to-end

• how to implement it with minimal user friction

• what signals would indicate this feature is actually working

This isn’t something I learned recently — it’s just how I reason about problems.

Even in my engineering role, I’ve always used a strong user-story mindset: understanding intent, questioning value, and sometimes even challenging whether something should be built at all.

Over time, I realized this is what more senior thinking actually looks like:

Not just implementing features, but deeply understanding intent and improving it when needed.

The Problem I Didn’t Have a Name For

In my side project, I started running into a subtle issue.

I would do most of the feature thinking upfront — naturally and consistently — before writing any code: planning how it would fit into the existing data model, how it would behave in the UI, and what the user experience would feel like end-to-end.

But once I started implementing, that thinking had nowhere to live.

If I stored it in a Linear ticket, it would get buried in execution details. More importantly, a Linear ticket — as a small unit of work — often didn’t represent the full end-to-end feature vision, only the initial increment being implemented.

If I stored it in Google Docs, it would quickly become something I forgot to revisit.

So I was left with a gap:

A lot of clarity before coding… and very little preservation of that clarity afterward.

Seeing PRDs Differently

I’ve seen PRDs before — usually as input documents in product discussions or strategic meetings. But I never had to write them myself.

For context, a PRD (Product Requirements Document) is a structured document used to define what a product or feature should do, why it exists, and how success is measured before development begins.

They felt formal, structured, and somewhat distant from how I naturally think when building.

That changed in this side project.

Because I am now both the product thinker and the implementer, I started noticing that I may need a simple framework to structure this type of thinking, and a persistent place to store it so it could eventually be referenced when implementing features in Linear.

Not as something I fully have — but as something that might be useful to formalize.

PRD-Lite: A Repeatable Thinking System (Emerging Idea)

Over time, I noticed I was already doing a fairly repeatable type of thinking — just informally.

To make it easier to reason about, I started sketching a simple structure I might use for future features. I’m considering storing it as a Markdown file in the repo so it stays close to the code and could eventually be referenced during implementation.

I haven’t adopted this yet, but it feels like a direction worth exploring.

🧾 PRD-lite format

1. Why it exists Why this should be built and what value it creates

2. MVP scope What the smallest useful version includes

3. User flow What the user does

4. Data model (light) What objects exist

5. Out of scope What I am explicitly not building

Right now, this is more of a thinking scaffold than a system — something I use to avoid losing structure while I’m reasoning about a feature.

The AI Layer: A Possible Extension of This Idea

Another thing I’ve been thinking about is how this kind of structured thinking might interact with AI coding assistants.

If I eventually write these PRD-like notes in the repo, they could serve as useful context when working with tools like Claude or similar assistants.

Instead of re-explaining intent in prompts, the assistant could potentially use:

• structured feature definitions

• scope boundaries

• user flows

• data model assumptions

This is not something I’m actively doing yet — but it’s one of the reasons this idea feels interesting.

It suggests a workflow where thinking becomes more portable between planning and implementation.

Why This Matters in a Side Project

When you’re building alone, there is no separation between:

• product thinking

• decision making

• implementation

Everything collapses into one continuous flow.

That makes it very easy to:

• lose intent while coding

• overbuild in the moment

• forget original assumptions

• drift away from the real problem you were solving

What I’m exploring here is not a process — it’s a way to preserve intent long enough to actually build from it.

Final Thought

I used to think PRDs were documents created for engineers to follow.

Now I see them differently.

They are not external instructions — they are a way to make your thinking persistent enough to actually build from it.

And for the first time building something on my own, I’ve realized I’ve naturally been doing product thinking all along — and I’m now starting to explore how to structure that thinking so it doesn’t get lost between idea and implementation.

Think clearly. Write it down. Build intentionally.

That’s the system I’m starting to discover

They help us explore faster, reduce friction, catch bugs in seconds, diagnose issues in minutes, refactor code precisely, and move through iterations at a pace that would have felt unrealistic not long ago.

All of that is objectively positive.

And yet, alongside those gains, something quieter has shifted — not in capability, but in how the work feels.

This article is an attempt to name that shift from the perspective of a senior developer working with AI-powered tools — not as a critique, but as a reflection on the feelings and navigation required in this new paradigm.

From building systems to shaping them

For much of my career, the relationship between effort and ownership was relatively clear.

You analyzed and built solutions.
You carried problems end to end.
You found and fixed issues opportunely.
You mastered your stack, sharpened your understanding of computer science, system design, and engineering — and used that as a guiding signal of how good you were becoming.

Today, that relationship is less predictable.

AI doesn’t just help write code — it can:

• propose the structure

• draft the solution

• fill in edge cases

• produce something that already works

When that happens, the output can be correct and high quality — yet still feel oddly distant.

We’ve shifted from knowing things at a very granular level to orchestrating tools and shaping systems into existence.

When contribution starts to feel ambiguous

I’ve noticed that how I feel about my contribution depends less on how much AI I use, and more on how I’m involved.

I feel more grounded when I:

• intentionally orchestrate the process

• participate actively in decision-making

• debug and investigate issues

• guide refactors toward something more mature

• go beyond the first iteration

• push for quality, correctness, tests, observability, and other core software engineering practices

In those moments, the work feels shaped, not just completed.

By contrast, when AI:

• proposes the structure

• drafts most of the solution

• resolves edge cases

• delivers something that already works

• resolves things quickly

…and my role is mainly to approve, lightly edit, and merge, a different feeling can emerge:

“I didn’t really contribute enough.”

The difference isn’t about typing versus not typing.
It’s about being necessary in the process.

How AI can aggravate impostor syndrome

This is where impostor syndrome can quietly enter — even for experienced developers.

Not because the work is poor.
Not because the system is fragile.
But because familiar signals of contribution are no longer reliable.

When AI takes a large portion of the work off my plate, it can provoke thoughts like:

• “I didn’t do this myself.”

• “I couldn’t have done this without help.”

• “How much of this was really me?”

The system may be better.
The outcome may be right.
But the internal sense of contribution can lag behind.

At times, this can feel like a lack of competence — but it’s really a paradigm shift.

Ways of recognizing value that worked for more than a decade — attention to detail, deeply caring about correctness and quality — don’t always map cleanly onto AI-assisted workflows or speedy shipment.

That mismatch can create doubt or unease, even when everything is working as intended.

A different shape of ownership

At senior levels, ownership no longer means:

• writing every line

• remembering every detail

• coming up with the architecture entirely on your own

It means:

• defining the right problem

• choosing the right constraints

• rejecting wrong or premature solutions

• integrating pieces into a coherent system

• being accountable when it breaks

When something fails, no one asks how much AI was involved.
They ask you — the engineer who shipped the solution — to stand behind it.

That responsibility hasn’t gone away, even if the path to it looks different now.

Closing

I don’t think I’m alone in experiencing this shift.

I suspect many senior developers are navigating something similar: working effectively with powerful tools, delivering solid systems, and still adjusting to how contribution and ownership feel in this new context.

This article itself was written with AI assistance — intentionally. Not to dilute the voice, but to reflect the reality it describes. The thoughts captured here represent feelings I’ve been sitting with as I navigate this new paradigm.

If this resonates, I’d be genuinely interested in hearing how others are experiencing this shift — what feels familiar, what feels different, and how you’re making sense of authorship and ownership in AI-assisted work.

Update – December 2024:
String Templates were available as a preview feature in Java 21 and Java 22.
However, the feature was withdrawn from Java 23 because the JDK team decided it required more design work before moving forward.
The concept is not canceled — it is expected to return in a future release with an improved design — but it is not available in Java 23.

Everything described in this article refers to the earlier preview versions (Java 21–22). I’m keeping the article online for educational purposes and will update it again when the new design becomes available.

String Templates are one of the most anticipated additions to modern Java. They were first introduced as a preview feature in Java 21, refined again in Java 22, and kept in preview in Java 23. They are expected to remain in preview until at least Java 24 or 25, when the design stabilizes enough to be finalized.

Even as a preview feature, String Templates are worth trying out. They significantly improve how developers construct strings in Java, and as a result, you will be better prepared when they are finalized.

What is this feature about?

String Templates allow embedding Java expressions directly inside string literals using the STR processor. This provides cleaner syntax for building structured strings and complements Text Blocks, making Java feel more expressive and modern.

Quick example:

String name = "Mirna";
String message = STR."Hello, \{name}! Today is \{LocalDate.now()}";
System.out.println(message);

Sample output:

Hello, Mirna! Today is 2025-01-01

How to run preview features:
If you are trying this with Java 21 or newer, you must enable preview mode, for a class for code that uses this feature like StringTemplatesDemo, we will need:

javac --enable-preview --release 21 StringTemplatesDemo.java
java  --enable-preview StringTemplatesDemo

Adjust the version number if you use a newer JDK (22, 23, etc.).

Common Use Cases

1. Build JSON cleanly

String user = "Mirna";
int score = 98;

String json = STR."""
{
  "user": "\{user}",
  "score": \{score},
  "active": true
}
""";

System.out.println(json);

2. Construct SQL dynamically

String table = "users";
String email = "mirna@example.com";

String query = STR."""
SELECT *
FROM \{table}
WHERE email = '\{email}'
""";

System.out.println(query);

3. Build HTML fragments

String name = "Mirna";

String html = STR."""
<p>Hello, <b>\{name}</b>!</p>
""";

System.out.println(html);

4. Use expressions directly

String math = STR."2 + 2 = \{2 + 2}";
String random = STR."Random value: \{Math.round(Math.random() * 10)}";

System.out.println(math);
System.out.println(random);

5. Use methods inside templates

String greet(String name) {
    return STR."Hello, \{name.toUpperCase()}!";
}

System.out.println(greet("Mirna"));

6. Combine Text Blocks + Templates

String language = "Java";
String feature = "String Templates";

String article = STR."""
## Feature Highlight

We're exploring \{feature} in \{language}.

Advantages:
- Readable
- Multiline
- Interpolated directly in code
""";

System.out.println(article);

Final Thoughts

String Templates make Java more modern and readable, especially when combined with Text Blocks. The feature is a meaningful improvement over string concatenation and String.format.

There are still two things that feel a bit unnatural to me.
First, the backslash before the curly braces (\{name}). Second, having to prefix a Text Block with STR.""" just to enable interpolation. Most modern languages do not require this extra step. I can live with both, though, since the improvement in readability is real.

I’m excited to see how this feature evolves as it moves toward finalization.

Quick note: I’m not affiliated with Cursor in any way. This is just my honest experience using it as part of my daily development flow.

Quick intro — what is Cursor?

Cursor is an AI-powered coding editor that acts like an extra (very eager) developer: it reads your repo, runs agent-style tasks, edits files, suggests fixes, and can even scaffold features. The real game changer for me is that Cursor has the whole codebase as context. You don’t need to paste files or explain the entire project — you just reference what you want, and it knows what you mean.

Pricing

Cursor has a free option and paid tiers. Honestly, the free tier didn’t help me much beyond getting a feel for the tool. The real value came once I switched to the paid plan, and I’m grateful my team enabled it for us. On paid plans you get a limited number of requests each month, and you can also set an extra buffer of requests if someone goes over — which is especially useful for teams.

My overall impression

I’m genuinely impressed. When you give Cursor a clear task with a simple scope and good instructions, it can really deliver. Some people compare it to having a junior dev working for you — eager to move fast and do as much as possible. I completely agree.

Where Cursor really helped me

• Bug fixing: Quick suggestions to try out, which makes debugging less painful.

• Asking questions about the codebase: Instead of searching forever, I just ask Cursor about specific parts of the repo.

• Implementing new features with clear scope: It’s great at well-defined, non-ambiguous tasks.

• Remembering syntax/commands: Especially across multiple languages and tools.

• Running commands directly: This feature has been surprisingly useful. Instead of switching back and forth, I can run commands right from Cursor and keep my flow.

But it’s not perfect

• It makes mistakes and sometimes gives “bandaid” fixes (like just adding a null check without solving the real root cause).

• It can get stuck repeating the same approach or stuck in general

• You still need to test, review, and ask hard questions. Think of it as a junior dev — you’re still the one driving.

• It might overengineer solutions at times

• AI hallucinates and gives you wrong answers or partially right ones

Things that helped me get more out of Cursor

• Split complex tasks into steps. Easier to validate each result.

• Use git intentionally. Feature branches, small commits, incremental progress, stashes, etc to record the steps that are in a good shape or acceptably good to go. That will save you when you need to reverse things safely

• Run QA and tests. Don’t trust the shiny “all fixed” message until you confirm.

• Ask for tests. Make Cursor write them, then review and improve.

• Provide detailed context. Logs, corner cases, knowns/unknowns, filenames, code fragment — the more thoughtful you are at providing guidance, the better the output.

• Track usage. Requests are limited, so I keep an eye on how many I’ve used.

• Pair it with ChatGPT. I use ChatGPT for general questions or planning, Cursor for codebase-aware tasks.

• Be specific when reverting changes. Otherwise, it might undo more than you expect.

• Batch steps into one request when possible. Saves credits.

• Keep learning prompt engineering. Makes a big difference in quality.

• Know when to pivot. If it’s stuck, switch strategies or take over manually.

• Still use docs/Stack Overflow/debugging. AI is great, but not everything.

And yes — don’t waste requests saying “thank you” 😅.

Final thoughts

I’d say Cursor is absolutely worth it. You just need to learn how to use it well: give it scope, guide it, question it, and keep testing. The better you are at driving, the more you’ll get out of it. For me, it’s taken a lot of the heavy lifting and repetitive tasks off my plate, while still leaving me in control of the important decisions.

What about you? Have you tried Cursor as your AI pair-programmer? How do you use it day-to-day? I would love to hear your experience as well!

🆕 What Is a Text Block?

A text block is a multi-line string literal introduced as a preview in Java 13 and officially added in Java 15. It allows you to write strings across multiple lines without having to escape every newline or quote.

Syntax

Text blocks are enclosed in three double quotes ("""), and must start on a new line:

String html = """
    <html>
        <body>
            <h1>Hello, World!</h1>
        </body>
    </html>
    """;

This is far more readable than:

String html = "<html>\n" +
              "    <body>\n" +
              "        <h1>Hello, World!</h1>\n" +
              "    </body>\n" +
              "</html>\n";

Where Can You Use a Text Block?

Anywhere you can use a regular string, you can use a text block. That includes:

• Assignments to variables

• Method arguments

• Return values

• Annotations

• Logs and templates

System.out.println("""
    This is a valid
    text block string
    used as an argument.
    """);

Text blocks shine when dealing with structured or long-form content:

• 🖥️ HTML/XML/JSON snippets

• 💾 SQL queries

• 🤖 Prompt engineering for AI

• 🧑‍🏫 Code samples for documentation

• 📜 Poetry, song lyrics, or long messages

String sql = """
    SELECT id, name
    FROM users
    WHERE active = 1
    ORDER BY name;
    """;

Smart Whitespace Handling: Incidental vs Essential

One of the most powerful features of text blocks is their ability to remove incidental white space—the indentation that's not part of the string itself but exists to align with your code.

Let’s visualize this with · characters to represent leading spaces.

👇 Example: Incidental White Space Removed

void writeHTML() {
    String html = """
········<html>
········    <body>
········        <p>Hello World.</p>
········    </body>
········</html>
········""";
    writeOutput(html);
}

✅ The output of html becomes:

<html>
    <body>
        <p>Hello World.</p>
    </body>
</html>

Java determines the minimum indentation level (based on the closing delimiter position) and removes it from all lines. This keeps your string readable and aligned with your code.

Preserving Essential White Space

To preserve indentation within the string, just move your content to the right:

void writeHTML() {
    String html = """
········    <html>
········        <body>
········            <p>Hello World.</p>
········        </body>
········    </html>
········""";
    writeOutput(html);
}

Result:

    <html>
        <body>
            <p>Hello World.</p>
        </body>
    </html>

Opting Out of Trimming Entirely

If you don’t want Java to trim anything, place the closing delimiter on the far left:

void writeHTML() {
    String html = """
                  <html>
                      <body>
                          <p>Hello World.</p>
                      </body>
                  </html>
""";
    writeOutput(html);
}

Java will treat every character as-is, preserving all leading spaces.

For all the nitty-gritty details, see JEP 355.

Normalize Line Terminators

Text blocks use \n (line feed) as the default line terminator on all platforms. If you need to convert them to your system-specific line separator (e.g. \r\n on Windows), you can do:

String adjusted = textBlock.replaceAll("\n", System.lineSeparator());

This ensures your strings behave consistently across environments.

New String Methods Introduced

Java 15 introduced several useful methods in the String class to complement and enhance the text block feature:

Example: 📄 formatted(...) with Text Blocks

You can use .formatted(...) directly on a text block to inject dynamic values:

String email = """
    Dear %s,

    Your order #%d has been shipped and is expected to arrive by %s.

    Thank you for shopping with us!
    """.formatted("Mirna", 12345, "Friday");

System.out.println(email);

Output:

Dear Mirna,

Your order #12345 has been shipped and is expected to arrive by Friday.

Thank you for shopping with us!

This makes text blocks a great fit for templated emails, prompts, or code generation — with clean syntax and no clutter.

📚 Official Documentation

Want to learn more or see additional examples? Check out the official guide:
👉 Text Blocks in Java 15

Conclusion

Text blocks are a small yet powerful improvement in Java that makes your code easier to read, write, and maintain—especially when working with structured or formatted content.

No more escaping newlines or cramming everything into one line. Just write clean, readable text!

🧭 Stay tuned for more in the Modern Java Features series!