DEV Community: Laurina Ayarah

The $100 Website Tier: What It Includes and Why I Offer It

Laurina Ayarah — Tue, 21 Jul 2026 20:48:16 +0000

I need you to look at this before I say anything else.

That's a live site I built. Private chef, artisan bakery, full booking flow, clean design, fully mobile responsive. And it cost the client $100.

People are usually shocked when I say that number out loud. The going rate for a single page site like this is normally $200 to $300, and I do build in that range too, depending on scope. But I also keep a $100 tier, on purpose, because I don't think everyone who needs a professional website should have to spend a lot of money to get one. Especially if you're a small business or just starting out.

So let me show you exactly what $100 got this client, and then I'll break down five types of websites I build at this price for people just like them.

The Project: Chef Marvv

Chef Marvv is a private chef and artisan baker based in Port Harcourt. He needed a site that felt premium, not like a template someone threw together in an afternoon.

Here's what the build included:

A hero section with his branding and a clear call to book
A signature services section covering private chef dining, artisan bakery, custom cakes, and event catering
An about section telling his story and years of experience

A booking section connected straight to WhatsApp so clients can inquire instantly
Full mobile responsiveness, because most of his clients are finding him on their phones, not a laptop

No clutter, no pages he didn't need, just a clean, fast, mobile friendly site that makes him look exactly as premium as his food actually is. That's the whole philosophy behind my $100 tier. Simple doesn't have to mean cheap looking.

Five Website Types I Build at This Price

1. Portfolio or Personal Brand Website

For creatives, consultants, and coaches who need one clean page to represent themselves online. Home, about, services, contact, footer. Fully mobile responsive, sharp enough to make a strong first impression.

2. Small Business Landing Page

Product or service focused, built to convert visitors into action. A clear breakdown of what you offer, plus a WhatsApp or Instagram click to chat button front and center. The goal isn't more pages, it's more DMs.

3. Online Restaurant or Cafe Site

Like Chef Marvv, but for food vendors who want customers to browse the menu and prices before ever messaging. Saves you the back and forth and makes ordering feel effortless on any device.

4. Service Booking Site

Perfect for nail techs, service providers, or anyone who books appointments. Pairs perfectly with WhatsApp and a calendar link so clients can see your services and book directly.

5. Digital Catalog Site

Product photos, prices, DM to order. A clean, scrollable digital shop window so customers already know what you sell before they reach out.

Why I Keep This Tier Around

I could charge more for all of these, and for bigger builds, I do. But I know what it feels like to be building something from nothing with limited resources. If a clean, mobile responsive, professional website for $100 helps someone take their small business seriously, that trade is worth it to me every time.

If you've been putting off getting a website because of cost, this might be your sign.

Drop a comment or reach out, I'd love to build yours next.

Email and LinkedIn in Bio

3000+ of you are here. I'm not over it.

Laurina Ayarah — Tue, 21 Jul 2026 16:40:12 +0000

I just looked at my dashboard and saw something that made me stop scrolling: 3,011 followers on DEV.

I want to sit here for a second and actually say thank you, properly, not just react with a heart emoji and move on.

How this even started

I'm Tobore. Some of you know me as Laurina Ayarah, the name still on my profile from before I started going by BuildWithTee. I'm a full-stack developer and a technical writer, and honestly, for a long time I thought I had to pick one. Turns out the two feed each other. Building things gives me something real to write about, and writing forces me to actually understand what I built well enough to explain it to someone else.

I started posting on here without a big plan. No content calendar, no growth strategy, just me writing about bugs I found, systems I shipped, and things I was learning in public. I did not expect people to stick around for it. You did.

What you've actually given me

Every comment, every reaction, every DM where someone said a post helped them debug something or made them feel less alone in this industry, all of that added up to something I did not see coming. Some of you have been here since my very first post. Some of you found me last week. All of it counts.

A few of you have reached out to talk, to ask questions about breaking into tech, to share your own wins, or to tell me my writing made a hard day a little easier. I read every single one of those messages, even the ones I take a while to reply to. Please know they land.

What I'm still building

I write to think out loud, and I build because I genuinely love making things that work for real people. Whether it's a silent bug that crashes live surveys, a system built for patients who cannot afford for it to fail, or just me trying to figure out CSS versus Tailwind at midnight, this space has become somewhere I can be fully myself as both a developer and a writer.

I'm not slowing down. There's more building, more writing, and more honest documentation of the process coming. If you've been here a while, thank you for staying. If you just followed me today, welcome; I promise it gets more interesting from here.

One ask

If there's a topic you want me to write about, a bug story you want to hear, or something about full-stack dev or technical writing you're curious about, drop it in the comments. I read all of them, and I'd love to write the next post for you specifically.

3,011 of you believed this was worth following. I don't take that lightly. Here's to whatever we build next.

With gratitude,
Tobore

Happy New Week DEV community!

Laurina Ayarah — Mon, 20 Jul 2026 08:41:12 +0000

I Found a Silent Bug in Formbricks That Crashes Live Surveys at Runtime

Laurina Ayarah — Sun, 19 Jul 2026 21:38:52 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

Formbricks is an open-source survey and experience management platform built with Next.js, TypeScript, React, and Tailwind CSS. It lets teams create and deploy surveys across websites, apps, and email. Developers can self-host it or use the cloud version. With over 12,000 GitHub stars and hundreds of contributors, it is one of the most actively maintained open source alternatives to Qualtrics.

Bug Fix or Performance Improvement

Formbricks supports custom regex validation rules on survey questions. A survey creator can set a pattern that user responses must match before they are accepted. The problem was in how that pattern was stored.

The validation schema for regex pattern rules only checked that the input was a non-empty string:

// Before the fix
export const ZValidationRuleParamsPattern = z.object({
  pattern: z.string().min(1),
  flags: z.string().optional(),
});

z.string().min(1) means "give me any string with at least one character." It does not verify that the string is actually a valid regular expression. So a survey creator could type [invalid as their pattern, the schema would accept it, it would be saved to the database, and then when a real user submitted a response, the system would try to run new RegExp("[invalid"), JavaScript would throw a SyntaxError, and the survey would crash silently at runtime.

The bug never surfaced during setup. It only appeared when a real user was trying to submit a real response.

Code

Pull Request: github.com/Tobore005/formbricks/pull/1

Here is the fix:

const isValidRegexPattern = (pattern: string): boolean => {
  try {
    new RegExp(pattern);
    return true;
  } catch {
    return false;
  }
};

const isValidRegexFlags = (flags: string | undefined): boolean => {
  if (flags === undefined) return true;
  try {
    new RegExp("", flags);
    return true;
  } catch {
    return false;
  }
};

export const ZValidationRuleParamsPattern = z.object({
  pattern: z
    .string()
    .min(1)
    .refine(isValidRegexPattern, {
      message: "Invalid regular expression pattern",
    }),
  flags: z
    .string()
    .optional()
    .refine(isValidRegexFlags, {
      message: "Invalid regular expression flags",
    }),
});

Two helper functions wrap RegExp construction in a try/catch. If JavaScript throws on an invalid pattern, the function returns false and the schema rejects the input with a clear error message before anything reaches the database.

My Improvements

The key decision was where to catch this error. I could have added the validation at the UI layer, showing an error in the survey editor when someone types a bad pattern. But UI validation can be bypassed. The right place to catch it is at the schema level, so even if someone sends a malformed pattern directly through the API, it gets rejected before touching the database.

I also validated both the pattern and the flags separately. An invalid flag like z is just as capable of throwing a SyntaxError as an invalid pattern, and the original code left flags unvalidated too. Both fields now go through runtime validation before the schema accepts them.

The .refine() approach keeps the fix minimal and readable. The named helper functions mean anyone reading the schema immediately understands what the validation is doing without needing to read a try/catch block inline.

Best Use of Sentry

To prove the bug was real and show exactly what would happen in production, I set up Sentry error monitoring and reproduced the crash in a Node.js environment.

I wrote a script that simulated what Formbricks was doing before the fix: accepting an invalid regex pattern string, then trying to compile it into a real RegExp object at runtime. Sentry captured the full crash with a complete stack trace pointing directly to the line where new RegExp(pattern) failed.

Sentry showed:

Error: SyntaxError: Invalid regular expression: /[invalid/: Unterminated character class
Exact file and line: index.js:13:17 in validateWithPattern
Full breadcrumb trail showing the sequence of events leading to the crash
Environment details including Node version, OS, and production context

The stack trace confirmed that without the fix, this error would reach real users silently. With the fix in place, the invalid pattern is rejected at the schema level and never gets the chance to crash at runtime.

Best Use of Google AI

I used Gemini to help me understand the full scope of the bug and verify that my fix was sound before submitting the PR.

I described the bug to Gemini and asked it to explain why unvalidated regex strings are dangerous and how a try/catch around RegExp construction fixes it. Gemini confirmed the danger, walked through the exact failure scenario, and explained the three stages of the fix: the attempt, the safety net, and graceful failure.

Gemini also asked whether I was planning to open a PR, which I confirmed I had already done. That conversation gave me confidence that the fix was complete and covered both the pattern and flags fields.

The Hardest System I Ever Built Was for Patients Who Could Not Afford for It to Fail

Laurina Ayarah — Sun, 19 Jul 2026 09:47:51 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

There is a version of this story where I walk you through the technical challenges in a clean, detached voice. Structured. Professional. Composed.

This is not that version.

Seven months. A hundred pages of documentation written alongside the code, not after it. A live system serving rural clinics in Delta State, Nigeria. And three bugs so specific and so cruel that each one felt designed to find the exact gap between what I thought I knew and what I actually knew.

The Delta Health Information and Appointment Booking System was my final year project at the University of Port Harcourt. That sentence makes it sound smaller than it was. This was a real system for real clinics, serving patients who travel for hours to reach a healthcare facility only to find the clinic is full, the doctor is not in, or nobody told them their appointment was cancelled. These are not hypothetical users. These are people whose access to healthcare depends on whether the software works.

That is a different kind of pressure than getting a good grade. And it did not start at deployment. Before a single line of code was written, I had to pitch the entire concept to my university supervisor, the Head of Department, the Faculty Dean, and an external examiner. The system had to be defensible not just technically but practically. It had to demonstrate that it solved a real problem that real people in Delta State were actually facing. I was presenting to people with decades of experience who would ask questions I had not thought of yet. That kind of scrutiny either sharpens you or breaks you. I chose to let it sharpen me.

The stack was React.js, Node.js, PHP with Laravel, MySQL, AWS, and Docker. Communication channels included SMS gateways, WhatsApp Business API, and USSD because not every patient in rural Delta State has a smartphone. The system had to run on 2G connections, on entry-level Android phones with 2GB RAM, in areas where electricity is inconsistent and internet is a bonus, not a guarantee.

Three bugs tested everything I thought I understood about building for real environments.

Bug 1: The Clinic That Appeared in the Ocean

I was proud of the location feature. Genuinely proud.

When a patient booked an appointment, the system pulled the GPS coordinates stored in the database and surfaced nearby clinics in order of proximity. For patients in rural areas who might not even know the name of the nearest clinic, this mattered. They were not booking at one specific facility. They were asking which healthcare facility they could actually get to.

The clinics table stored latitude and longitude as DECIMAL(10,7) fields. The booking module queried them, the frontend rendered them, and in development everything worked perfectly. Then we moved into field testing with real clinic data that real administrators had entered manually from printed forms.

That is when a clinic in Delta State appeared off the coast of Ghana.

Not metaphorically. On the map. In the ocean.

I sat back and just stared at it for a minute.

The database was not wrong. MySQL had accepted every value without complaint because the values were technically valid decimals. The problem was simpler and more human than that. Clinic profiles were being set up by administrators entering coordinates manually from printed reference sheets, and transcription errors crept in during that process. Some records had latitude and longitude completely swapped. Others had digits missing or duplicated from misreading handwritten numbers. Six degrees of longitude and five degrees of latitude are both perfectly valid decimal numbers. MySQL stored them without question. They just pointed to the ocean.

The fix had two parts. I added a server-side validation layer in the Node.js API that checked every incoming coordinate pair against Nigeria's geographic bounding box before writing to the database. If a coordinate fell outside that box, the record was flagged for review and not saved. Then I wrote a one-time audit script to go through every existing record, pull the outliers, and mark them for manual correction.

// Validate coordinates fall within Nigeria's bounding box
function isValidNigerianCoordinate(lat, lng) {
  const NIGERIA_BOUNDS = {
    minLat: 4.0,
    maxLat: 14.0,
    minLng: 2.7,
    maxLng: 15.0
  };
  return (
    lat >= NIGERIA_BOUNDS.minLat &&
    lat <= NIGERIA_BOUNDS.maxLat &&
    lng >= NIGERIA_BOUNDS.minLng &&
    lng <= NIGERIA_BOUNDS.maxLng
  );
}

if (!isValidNigerianCoordinate(lat, lng)) {
  return res.status(400).json({ 
    error: 'Coordinates fall outside expected geographic boundary. Please verify and resubmit.' 
  });
}

Six clinics had swapped coordinates. Three had digits that had been misread during manual entry. All nine were placing facilities somewhere they had no business being.

The lesson: Validate coordinates against geography, not just against data types. A number can be perfectly valid and completely wrong at the same time.

Bug 2: The Notifications That Went Nowhere

This one hurt differently.

The communication layer was the part of this system I had worried about most during planning. Patients needed appointment confirmations and reminders through whatever channel their phone supported. SMS for basic phones. WhatsApp for smartphones. USSD as a fallback. The notifications table tracked every outgoing message with a type, content, status, and timestamp.

During integration testing, everything looked correct. API calls returned 200 status codes. The notifications table showed a status of sent for every message dispatched. I moved into field testing feeling reasonably confident.

Then a clinic administrator in the pilot told me that none of the patients had received their reminders.

None.

I pulled up the notifications table. Every record showed sent. I checked the API logs. Every call had returned 200. From every technical indicator I had, the messages were going out.

They were not going out.

It took three days to understand what was actually happening. The SMS gateway had a two-stage delivery model I had not fully read in the documentation. When our server sent a batch of notifications, the gateway accepted them and returned 200. That response confirmed the gateway had received the messages. It did not confirm delivery to the recipient. Actual delivery was asynchronous. The gateway would attempt delivery and then, if we had registered a webhook URL, call back to update the final delivery status. We had not registered a webhook. Messages were entering the gateway's queue, some delivering and some failing, and we had no visibility into any of it because we were reading sent as if it meant delivered.

It did not mean delivered. It meant accepted by the gateway. Those are different things.

// What we had before (wrong)
const sendNotification = async (userId, message) => {
  const response = await smsGateway.send({ to: phone, body: message });
  if (response.status === 200) {
    await db.notifications.update({ status: 'sent' }); 
    // WRONG: this is gateway receipt, not delivery
  }
};

// What we built after (correct)
const sendNotification = async (userId, message) => {
  const response = await smsGateway.send({ 
    to: phone, 
    body: message,
    webhookUrl: `${process.env.BASE_URL}/webhooks/delivery-receipt`
  });
  await db.notifications.update({ status: 'queued' }); // Honest status
};

// Webhook handler for actual delivery confirmation
app.post('/webhooks/delivery-receipt', async (req, res) => {
  const { messageId, status } = req.body;
  await db.notifications.update({ 
    messageId, 
    status: status === 'delivered' ? 'delivered' : 'failed' 
  });
  if (status === 'failed') {
    await retryQueue.add({ messageId }); // Queue for retry
  }
  res.sendStatus(200);
});

After these changes, confirmed delivery in the pilot went from what I can only describe as catastrophically low to 94%. The remaining 6% were phones that were switched off or numbers that were unreachable, which is a real baseline in any rural environment.

The lesson: A 200 from a messaging API is an acknowledgement, not a guarantee. Read the documentation past the quickstart. Implement webhooks. Never trust a status you did not actively confirm.

Bug 3: The Bug That Only Existed in the Real World

This one was the most frustrating because I could not reproduce it in development.

The system was built to be bandwidth-tolerant. The health education hub had offline caching. The UI was optimized for slow connections. I thought I had accounted for the network.

What I had not accounted for was what happens to a database transaction when a patient starts a booking, the connection drops mid-transaction, connectivity returns, and the patient hits submit again because nothing happened the first time.

During the field pilot we started seeing duplicate appointments. Same patient. Same clinic. Same time slot. Two confirmed bookings in the database. I could not reproduce this in development because our development environment had stable internet. The bug only existed where the internet was not stable, which was the exact environment this system was built for.

The sequence was this: patient initiates booking, client generates the request, connection drops before the request reaches the server, client shows a loading state, connection returns, patient re-submits, both requests eventually reach the server, both are accepted and written because nothing in the database logic detected they were the same request.

The fix was idempotency keys.

// Client side: generate a unique key per booking attempt
const initiateBooking = async (bookingData) => {
  const idempotencyKey = `booking_${userId}_${clinicId}_${slotId}_${Date.now()}`;

  // Store key locally before sending
  localStorage.setItem('pendingBookingKey', idempotencyKey);

  const response = await fetch('/api/appointments', {
    method: 'POST',
    headers: { 
      'Content-Type': 'application/json',
      'Idempotency-Key': idempotencyKey
    },
    body: JSON.stringify(bookingData)
  });

  if (response.ok) {
    localStorage.removeItem('pendingBookingKey');
  }
};

// Server side: check key before processing
app.post('/api/appointments', async (req, res) => {
  const idempotencyKey = req.headers['idempotency-key'];

  const existing = await db.appointments.findByKey(idempotencyKey);
  if (existing) {
    return res.status(200).json(existing); // Return original response
  }

  const appointment = await db.appointments.create({
    ...req.body,
    idempotencyKey
  });

  res.status(201).json(appointment);
});

I also added a client-side request state machine so the UI accurately reflected whether a booking was pending, confirmed, or failed. And I added local caching so a booking initiated during a dropped connection would retry automatically when connectivity returned.

The lesson: Test your system in the conditions it will actually run in. A stable development environment hides entire categories of bugs that only exist where infrastructure is unreliable. Idempotency is not a nice-to-have. It is the difference between one booking and two.

What Seven Months Felt Like

I want to be clear about something. These bugs were not exotic. They were not especially clever to find. What made them hard was that each one required me to step outside the assumptions I had built into my mental model and confront the reality of how real people in a real environment were actually using the system.

Administrators made transcription errors entering coordinates from printed sheets because the data entry process had no validation to catch them. Patients re-submitted forms because nothing visually confirmed their action had worked. A gateway returning 200 seemed like enough confirmation because in most environments it would be.

None of my assumptions was unreasonable. They just were not built for this specific context.

I was also documenting everything in parallel because I was building a system that had to outlast my involvement. The team maintaining this after my final year ended needed to understand not just what the code did but why every decision was made. Writing down the reasoning behind every fix, not just the fix itself, is something I carry into every project now.

The system is live at deltahealth.usestudybuddy.org. Patients in Delta State use it. Clinics that had no digital infrastructure now have a real-time view of their appointment flow and a way to reach patients before they make a wasted journey.

I am proud of what it does. I am prouder of how many times it almost didn't work and we fixed it anyway.

I am Tobore, a full-stack developer and Best Author on DEV for React writing. I built the Delta State Health Information and Appointment Booking System and I write about tools that actually change how developers work. Find more at dev.to/toboreeee.

Hey DEV, I'm Tobore. Let's actually connect.

Laurina Ayarah — Fri, 17 Jul 2026 07:48:18 +0000

Hey DEV, I'm Tobore. Let's actually connect.

I've been on here for a while now, mostly writing and lurking, but I realized I don't actually know that many of you. So this is me fixing that.

I'm based in Port Harcourt, Nigeria. I build websites, and I also do technical documentation and content writing. Most of what I write comes from projects I've actually built or shipped, not stuff I read about somewhere. I currently hold the DEV React Top Author badge and I recently won the Google I/O 2026 Writing Challenge for Technical Writers.

Right now I'm building my career, taking on freelance dev and writing work, and studying for AWS SAA-C03 on the side. I also run BuildWithTee, which is basically my attempt at building in public: code, write, connect.

What I'm looking for here

Other devs and technical writers to swap notes with
People building things in public who want an accountability buddy or just someone to bounce ideas off
Anyone doing tech documentation or content writing who wants to talk shop
People across continents, not just Nigeria or Africa. I want this to be genuinely global

If any of that sounds like you, drop a comment. Tell me what you're working on, what you're learning, or just say hi. I reply to everyone.

Let's connect: LinkedIn
Email's in my bio.

Looking forward to actually knowing some of you instead of just reading your posts silently 😅

Claude Sonnet 5 Just Shipped: Here's What Changed and What to Use Right Now

Laurina Ayarah — Wed, 01 Jul 2026 21:16:06 +0000

Anthropic released three model updates in five weeks. If you have not been watching the changelog closely, it is easy to miss how much shifted underneath you in that window. I put this together to make sense of what actually changed, what each model is for, and what I would actually recommend using right now.

The short version

Claude Opus 4.8 landed May 28, 2026. A reliability upgrade to Opus, not a new tier.
Claude Fable 5 and Claude Mythos 5 landed June 9, 2026. The first models in a new tier above Opus, called Mythos class.
Claude Sonnet 5 landed June 30, 2026. The newest generally available model, and now the default on Free and Pro plans.

If you only take one thing from this, take the last point. Sonnet 5 is the model most developers will be using day to day, and it is a meaningful step up from Sonnet 4.6, not just an incremental one.

Claude Sonnet 5: the one that matters for most of us

Sonnet 5 is built for agentic coding, tool use, reasoning, and everyday professional work, at a lower cost than Opus. A few specifics worth knowing before you switch over:

1M token context window. A token is roughly three-quarters of a word, so this means Sonnet 5 can hold around 700,000+ words of conversation or code in mind at once before it starts losing track of earlier parts. In practice, that is enough to work across an entire codebase or a long document in a single session.
128K max output tokens. This is the cap on how much it can generate in one single response, close to 96,000 words. It is separate from the context window above, which is about what it remembers, not what it produces.
Adaptive thinking is on by default, manual extended thinking has been removed. Older Claude models let you manually switch on a "think longer before answering" mode for harder problems. Sonnet 5 decides for itself when to slow down and reason more, based on the task, so that the manual switch is gone.
A new tokenizer. A tokenizer is the system that breaks your text into tokens, which is how usage and cost are measured. Sonnet 5 uses a different tokenizer than Sonnet 4.6, so the exact same sentence now counts as up to 35% more tokens than it used to. This does not affect what the model can do, but it does affect anyone tracking or budgeting API usage.
Introductory pricing of $2 / $10 per million tokens through August 31, 2026, moving to $3 / $15 after that. This means $2 for every million tokens you send in, and $10 for every million tokens it sends back, at the promotional rate. After August 31, it rises to $3 and $15. This only applies if you are using the API directly, not to a regular Claude.ai subscription.

The tokenizer change is worth sitting with for a second, because the two points above connect. Since the same prompt now costs more tokens, and Anthropic knows that, they've priced Sonnet 5 lower for now to roughly offset it. Your bill should stay close to what it is now, but once the introductory pricing ends in August, it is worth doing the math again rather than assuming your costs will stay flat.

Model ID for the API:

claude-sonnet-5

If you are on Claude Code, it is already set as the default model as of version 2.1.197.

Where Opus 4.8 fits now

Opus 4.8 was not replaced by Sonnet 5, it sits alongside it. The headline change with 4.8 was reliability rather than raw benchmark gains. Anthropic reported it is roughly four times less likely than Opus 4.7 to let flaws in its own generated code pass without flagging them, and it posted a strong score on Online-Mind2Web for browser agent tasks.

Opus 4.8 also introduced an effort parameter, letting you choose between standard, extra, and max effort depending on how much reasoning a task actually needs. That parameter carried over into Sonnet 5 as well.

My working rule of thumb: reach for Opus 4.8 on complex architecture decisions, long agentic sessions, and heavy computer use work. Reach for Sonnet 5 for the daily coding, tool use, and knowledge work that used to default to Sonnet 4.6.

The new tier: Fable 5 and Mythos 5

This is the part of the announcement that got the least coverage relative to how significant it is. Anthropic introduced a tier above Opus called Mythos class, and the first two models in it are Claude Fable 5 and Claude Mythos 5.

Both share the same underlying capabilities. The difference is safety scope:

Claude Fable 5 is the generally available version. It includes safety classifiers that automatically route flagged requests, mainly around cybersecurity and biology, to Claude Opus 4.8 instead.
Claude Mythos 5 does not include those classifiers. It is limited to approved organizations through Project Glasswing, invitation only, with no self serve signup.

If you are building on the API and calling Fable 5, plan for a few behaviors that were not a concern with Opus or Sonnet models: new response handling for refusals, since the classifier can decline a request before generating output; a fallback path for retrying on another model when that happens; and the fact that you are not billed for a request refused before output generation, with retries on a different model refunding the prompt cache cost of the switch.

Availability on Fable 5 and Mythos 5 has been inconsistent since launch. I am currently on the Free plan, and Fable 5 appeared in my own model picker labeled "Included until July 7," which suggests this is a limited trial window rather than standing access. There were also reports shortly after launch of a temporary suspension tied to an export control directive. If your work depends on either model, I would treat availability as unconfirmed until you check it directly, rather than assuming day one access holds.

Quick comparison

Model	Released	Tier	Best for
Claude Sonnet 5	June 30, 2026	Sonnet	Daily coding, agents, knowledge work, lower cost
Claude Opus 4.8	May 28, 2026	Opus	Complex architecture, long agent sessions, browser/computer use
Claude Fable 5	June 9, 2026	Mythos (public)	Hardest coding and long horizon agentic work, with safety routing
Claude Mythos 5	June 9, 2026	Mythos (restricted)	Same as Fable 5, approved orgs only, no classifiers

What to actually do this week

If you are already on Sonnet 4.6, move to Sonnet 5. Pricing is close to cost neutral during the introductory window, and the agentic gains are real rather than marginal.

If you are running production workloads on Opus for cost reasons, benchmark Sonnet 5 against your actual tasks before assuming you still need Opus. Anthropic's own numbers show Sonnet 5 slightly outperforming Opus 4.8 on some knowledge work evaluations, which was not the case with earlier Sonnet generations.

If Fable 5 or Mythos 5 shows up as an option for you, treat it as something to evaluate rather than something to build a critical workflow on, at least until access stabilizes.

Anthropic's release cadence is not slowing down, and the gap between a new model shipping and it becoming the default everywhere keeps shrinking. It is worth checking the changelog more often than feels necessary right now.

I am Tobore, a full-stack developer and Google I/O 2026 Writing Challenge winner. I write about tools that actually change how developers work. More at dev.to/toboreeee.

How AI Is Reshaping Software Development and the Tech Industry in 2026

Laurina Ayarah — Fri, 29 May 2026 19:37:12 +0000

Three weeks ago, I stopped writing to watch history unfold. What I witnessed in those twenty-one days changed everything I thought I knew about software development. An engineer at a Fortune 100 company reduced a nine-day pull request cycle to 2.4 days. A Latin American fintech company completed an eight-year migration project in weeks instead of years with a 12x efficiency improvement. TypeScript surpassed both Python and JavaScript to become the most-used language on GitHub for the first time.

This isn’t incremental progress. This is a fundamental transformation of how software gets built.

Welcome to 2026, where 46% of all code written by active developers comes from AI, where 20 million developers use AI coding assistants daily, and where autonomous agents write, test, debug, and deploy entire features while we sleep. The future arrived faster than anyone predicted. And if you blinked during these past three weeks, you missed the moment everything changed.

The Numbers That Tell the Real Story
Let me hit you with the data that kept me awake at night, the statistics that made me realize I needed to write this article:

43.2 million pull requests were merged on GitHub each month in 2025, a 23% increase from the prior year. The annual number of commits pushed jumped 25% year-over-year to nearly 1 billion. This isn’t just growth. This is an explosion.

GitHub activity reached unprecedented levels in 2025, with developers merging 43 million pull requests monthly and pushing 1 billion commits annually, signaling a major industry shift as AI becomes central to software development.

GitHub Copilot reached 20 million cumulative users by July 2025, adding 5 million users in just three months. That’s more of a stampede than an adoption. 90% of Fortune 100 companies now use GitHub Copilot, validating AI coding assistants as enterprise-grade infrastructure rather than experimental toys.

But here’s what really matters: developers retain 88% of AI-generated code in final submissions. Think about that. AI isn’t generating throwaway suggestions that developers then completely rewrite. It’s producing production-ready code that makes it into your banking app, your social media feed, and your healthcare portal.

On average, Copilot writes nearly half of a developer’s code, with Java developers seeing up to 61% AI generation. In controlled studies, developers completed tasks 55% faster using Copilot, with pull request times dropping from 9.6 days to 2.4 days — a 75% reduction in development cycle time.

Let that sink in. Tasks that took more than a week now take less than three days. That’s revolutionary.

From Autocomplete to Autonomous
Two years ago, GitHub Copilot was impressive for suggesting the next line of code. You’d type a function name, and boom, it would complete the implementation. Developers praised it. Skeptics dismissed it as “fancy autocomplete.”

They were all wrong about what was coming next.

In 2025, agentic AI systems transformed LLMs from coding assistants into dynamic tools where users set goals and autonomous agents execute tasks. We’re not talking about suggestions anymore. We’re talking about agents that understand your entire codebase, plan complex multi-file changes, write tests, debug failures, and iterate until everything works.

According to IBM’s VP of Quantum and AI, software development is evolving from informal “vibe coding” to structured Objective-Validation Protocol, where humans define objectives and validate progress while agents handle execution.

The difference between old AI and new AI is the difference between a calculator and an intern. The calculator waits for you to tell it what to add. The intern takes your problem, figures out how to solve it, encounters obstacles, researches solutions, and delivers working code.

Meet the New Generation: Agents That Actually Work
GitHub Copilot evolved beyond inline suggestions. The Copilot coding agent launched in March 2025 and created over 1 million pull requests between May and September 2025. The platform introduced “repository intelligence”, AI that understands not just lines of code but the relationships and history behind them, analyzing patterns to figure out what changed, why, and how pieces fit together.

80% of new developers on GitHub now use Copilot within their first week. These early exposures reset what “easy” means for an entire generation of programmers. When AI handles boilerplate and error-prone syntax, developers stop avoiding powerful but complex tools and start picking based on utility instead.

Devin by Cognition Labs represents pure autonomous coding. Devin correctly resolves 13.86% of real-world GitHub issues end-to-end, far exceeding the previous state-of-the-art of 1.96%. That’s a 7x improvement over what existed before.

But percentages don’t capture the visceral reality. Watch Devin work and you’ll see something unsettling: Devin writes, runs, and tests code autonomously, handling everything from code refactoring to reviewing PRs, building internal tools, and fixing bugs before they hit your backlog.

The Nubank case study demolishes any remaining skepticism: Engineers delegated migrations to Devin and achieved a 12x efficiency improvement in engineering hours saved, with Data, Collections, and Risk business units completing migrations in weeks instead of months or years. An eight-year-old, multi-million-line codebase. Weeks, not years.

Claude Code by Anthropic might be the most impressive of all. Claude Code achieved a 77.2% score on SWE-bench Verified — the highest reported as of late 2025, solving real-world GitHub issues end-to-end. More remarkably, Claude Code maintains coherence through 30+ hour complex, multi-step coding workflows, while earlier models struggled with sessions lasting just a few hours.

Think about that. Thirty-plus hours of continuous, coherent work. That’s longer than most humans can maintain focus on complex coding tasks.

Cursor, Amazon Q Developer, and dozens more crowd a suddenly explosive market. The market for autonomous AI and agents will grow about 40% annually from $8.6 billion in 2025 to $263 billion in 2035. We’re watching an industry birth in real-time.

What Actually Changes When Code Writes Itself
The productivity statistics sound impressive until you realize what they actually mean for how software development works:

The Death of Boilerplate Hell Remember spending hours writing CRUD endpoints? Setting up authentication for the millionth time? Writing the same unit test patterns across different modules? That work is gone.

AT&T reports building an internal curated data product in 20 minutes using AI-fueled coding work that would have taken 6 weeks without AI. Their framework is trained to adhere to rigorous code discipline for quality, security, and compliance, producing production-grade code on demand.

Non-technical teams now use plain language prompts to build software prototypes, which AI-fueled coding turns into full products within hours instead of weeks. The barrier between “idea” and “working software” collapsed.

Junior Developers Learn at Superhuman Speed For engineers new to a codebase, Copilot resulted in a 25% speed increase by helping them navigate unfamiliar files more quickly. But speed isn’t the real story, understanding is.

New developers traditionally spend months learning a codebase before contributing meaningfully. With AI assistants that explain code, suggest patterns, and show how pieces connect, that learning curve compresses dramatically. 80% of developers successfully adopted Copilot, with initial users showing a 96% success rate in getting it to work productively.

Senior Engineers Become Force Multipliers The most profound change isn’t that AI does junior work, it’s that AI enables one senior engineer to do the work of a 5-person team. Experienced developers spend less time typing and more time on what actually matters: architectural decisions, system design, understanding business requirements, and solving novel problems.

With AI-fueled coding, developers wear multiple hats in the software development lifecycle, from product owners to architects, reducing cycle times and time to operation. The distinction between “roles” blurs when AI handles the implementation grunt work.

Code Quality: Better Than Expected, Worse Than We Need Here’s where reality gets complicated. GitHub research showed code readability improved 3.62%, reliability increased 2.94%, maintainability rose 2.47%, and conciseness improved 4.16% with Copilot. AI-assisted code passes peer review more frequently than manually written code, with code approval rates rising 5% and lines without readability errors increasing 13.6%.

But…and this is critical, 29.1% of Python code generated by Copilot contains potential security weaknesses. Around 46% of developers say they don’t fully trust AI outputs, noting suggestions are often “almost right but not fully correct”.

The pattern emerging across the industry: 75% of developers manually review every AI-generated code snippet before merging. AI isn’t replacing human judgment; it’s accelerating the generation phase while maintaining human verification as essential.

The Hidden Cost: Code Churn and Technical Debt Not everything is rosy. According to GitClear’s analysis of over 153 million lines of code, code duplication is up 4x with AI, and short-term code churn is rising, suggesting more copy/paste and less maintainable design.

AI excels at generating code that works. It struggles with generating code that’s architecturally sound for long-term maintenance. The danger isn’t that AI writes bad code, it’s that AI writes working code so quickly that teams ship features before addressing structural problems.

The “Vibe Coding” Era
In 2026, we’re witnessing a fundamental shift from AI tools that merely suggest code to autonomous AI agents that build entire features with minimal human intervention, the era of “vibe coding” where developers describe what they want in plain English and watch AI agents do the heavy lifting.

I’ve seen this firsthand. A non-technical product manager describes a feature: “I need a dashboard showing user engagement over time, with filters for date range and user segments, styled to match our design system.” Three hours later, a working implementation exists, complete with responsive design, error handling, and unit tests.

This isn’t hypothetical future tech. 72% of developers now use AI tools daily, and these tools contribute to approximately 42% of all committed code.

The workflow looks like this:

Describe the goal: “Migrate this authentication system from Auth0 to our new in-house solution”
Agent analyzes: Reviews your current implementation, reads documentation, and understands the architecture
Agent plans: Breaks the task into subtasks, identifies dependencies, and estimates complexity
Agent implements: Writes code, runs tests, catches failures, debugs, and iterates
Agent delivers: Opens PR with detailed description, responds to review comments
You’re not pair programming anymore. You’re delegating to a tireless junior engineer who never sleeps, never complains, and learns from every mistake instantly.

What This Means for Different Players in the Industry
For Individual Developers: The Skill Shift
AI-savvy developers earn more, with entry-level AI roles paying $90K-$130K versus $65K-$85K in traditional dev jobs. The market is rewarding those who master AI collaboration, not those who resist it.

The skills that matter in 2026 look dramatically different:

Declining Value:

Speed typing code
Memorizing syntax
Writing boilerplate
Finding documentation
Rising Value:

Prompt engineering and AI delegation
System architecture and design
Understanding AI-generated code quickly
Catching subtle bugs in plausible-looking code
Breaking complex problems into AI-delegable tasks
Developers report saving 30–60% of time on coding, testing, and documentation when using AI tools, freeing them up for higher-value work. But “higher-value work” requires different skills than what made someone a great developer five years ago.

For Engineering Teams: The Productivity Paradox
Here’s the dirty secret nobody talks about: individual developers show massive productivity gains, but when engineering leaders look at throughput, quality, and delivery velocity, company-wide delivery metrics often remain flat.

Why? Because, as the DORA 2025 report explains, AI acts as both “mirror and multiplier” in cohesive organizations with solid foundations, AI boosts efficiency; in fragmented ones, it highlights and amplifies weaknesses.

Teams with strong version control practices, quality internal platforms, and a user-centric focus see compounding gains. Teams with siloed communication, inconsistent processes, and technical debt see amplified chaos. AI doesn’t create organizational excellence, it magnifies what already exists.

For Companies: The Strategic Opportunity
Kate Blair of IBM predicts 2026 as the year multi-agent systems move into production, following the year of the agent in 2025. Companies treating this as an individual productivity tool miss the point entirely.

Organizations are building “AI factories” internal infrastructure for all forms of AI, including analytical, generative, and agentic. Companies without this infrastructure force data scientists and AI-focused businesspeople to replicate the hard work of figuring out tools, data, and methods, making AI more expensive and time-consuming to build at scale.

Consider Amazon’s internal deployment of AI coding tools, which saved an estimated 4,500 developer-years of effort and $260 million in one large migration project. That’s the scale of impact when AI coding integrates into organizational infrastructure, not just individual workflows.

For Tech Industry: The Market Reshaping
Advancements in AI and cloud computing are reshaping how businesses operate, forcing organizations to adopt these technologies to strengthen their positions in competitive landscapes. The software development market itself is transforming:

85% of leaders and 78% of managers use generative AI in regular work, though only 51% of frontline employees reported using GenAI in 2025
Grand View Research predicts the AI governance market, estimated at $308.3 million in 2025, will surpass $1.42 billion by decade’s end
Microsoft’s Q1 2025 market study reveals AI investments now return an average of 3.5X, with 5% of companies reporting returns as high as 8X.
Competition is intensifying. Beyond Cursor and GitHub, competitors include Google, which acquired Windsurf leaders Cognition (maker of Devin), and OpenAI and Anthropic, building AI coding offerings with in-house models. Every major tech company recognizes AI coding as strategic, not supplementary.

The Challenges Nobody Wants to Talk About
The Trust Problem
Around 46–68% of developers report quality issues or incorrect outputs from AI tools. The acceptance rate for AI suggestions hovers around 27–30%, meaning 70% of what AI generates gets rejected.

That’s simultaneously impressive (30% is useful!) and terrifying (70% is wrong!). The danger emerges when developers stop critically evaluating AI output, trusting plausible-looking code that contains subtle bugs or security vulnerabilities.

The “AI Workslop” Phenomenon
A concerning trend dubbed “AI workslop” has emerged, where AI-generated content appears polished but lacks substance, ultimately hampering productivity. This manifests as AI tools producing code snippets or designs requiring extensive human revisions, undermining efficiency gains.

Developers must adopt rigorous testing and human oversight strategies, transforming AI from a productivity killer into a reliable ally through critical evaluation over blind reliance.

The Skill Degradation Risk
When AI handles routine tasks, junior developers miss crucial learning experiences. Understanding why code works matters more than ever, but opportunities to build that understanding through repetition are disappearing.

The industry needs new onboarding approaches that balance AI productivity with skill development. Letting AI handle everything creates a dangerous dependency for developers who can’t code without AI.

The Employment Question
Despite fears, the US Bureau of Labour Statistics projects software development employment will grow, with AI complementing work rather than displacing developers. Database administrators are expected to grow by 8.2%, while database architects are projected to experience a 10.8% increase over 2023–33.

But “growth” doesn’t mean “no disruption.” Entry-level positions requiring primarily coding execution skills face pressure. Devin replaces tasks, not roles, acting as a force multiplier, allowing one senior engineer to do the work of a 5-person team. Teams might hire fewer developers while expecting remaining developers to leverage AI for greater output.

What’s Coming Next: The 2026 Roadmap
Multi-Modal AI Becomes Standard
Multimodal AI models will perceive and act in a world much more like humans, bridging language, vision, and action together. Devin can now process UI mockups from Figma and video screen recordings to understand visual bugs.

Imagine describing a UI: “Make it look like Stripe’s checkout page but with our brand colours.” The AI sees Stripe’s page, understands the design patterns, and implements a similar experience. We’re moving from text-to-code toward vision-to-code.

AI-Generated Code Reaches Majority
Around 41% of all code written in 2025 is AI-generated. Current trajectories suggest crossing 50% by late 2026 in organizations with high AI adoption. Google reports 25% of their code is AI-assisted, with CEO Sundar Pichai citing engineering velocity gains of approximately 10%.

The tipping point approaches where more code is AI-generated than human-written, fundamentally changing what “software development” means.

The Rise of Spec-Driven Development
Development is shifting toward focused working sessions where tasks that once required weeks of cross-team coordination become concentrated efforts. Instead of writing code, developers will increasingly write specifications that agents implement.

This mirrors historical shifts: assembly to high-level languages, procedural to object-oriented, monoliths to microservices. Each abstraction level raised productivity by letting developers think at higher levels.

Dynamic “Surge” Staffing
Organizations envision dynamic “surge” staffing, bringing in specialists on-demand for specific challenges and shifting resources without traditional productivity ramps. AI agents maintaining codebase knowledge enable consultants and contractors to contribute immediately, without multi-week onboarding.

The Quantum-AI Convergence
IBM publicly stated that 2026 will mark the first time a quantum computer outperforms a classical computer, unlocking breakthroughs in drug development, materials science, and financial optimization. AMD and IBM are exploring the integration of AMD CPUs, GPUs, and FPGAs with IBM quantum computers to accelerate algorithms outside the current reach of either paradigm, working independently.

Software development for quantum-classical hybrid systems represents entirely new territory where AI assists in managing complexity that humans alone cannot comprehend.

Best Practices: How to Actually Win with AI Coding
After analyzing thousands of implementations, clear patterns separate teams thriving with AI from those struggling:

Establish Patterns Before Generating
AI is fantastic at following established patterns but struggles to invent them cleanly. Define your first few endpoints or components with strong structure, and AI will follow those patterns. Start with chaos, and AI amplifies it.
Test AI-Generated Code Harder, Not Less
There’s a temptation to trust AI output because it “looks right” and passes initial checks — resist that. The most dangerous bugs hide in plausible-looking code. Increase test coverage for AI-generated code, not decrease it.
Track What AI Generates, Not Just How Much
Copilot usage metrics dashboard lets you see beyond acceptance rates, tracking daily and weekly active users, agent adoption, lines of code added and deleted, and language and model usage patterns across organizations.

Organizations need visibility into AI impact at the team and organizational levels, not just individual productivity.

Prepare for Velocity Jumps
AI-assisted development often produces a 20–30 per cent throughput increase, but higher throughput means architectural drift can accumulate faster without the right guardrails. Standardize before scaling. Document patterns. Make architectural decisions explicit.
Maintain Human-in-the-Loop Always
It’s important to have human-in-the-loop AI so humans can fine-tune and change the skill. Autonomy doesn’t mean removing human oversight. Every major AI coding implementation maintains human review, approval, and strategic direction.

Real Talk: Should You Be Worried?
Three weeks watching this unfold taught me something crucial: the question isn’t “Will AI replace developers?”

The question is: “What kind of developer thrives in 2026?”

Far from making human developers obsolete, AI augments their capabilities, fostering demand for those who operate at the intersection of technology and innovation. Developers using AI tools are twice as likely to report feeling happier, more fulfilled, and regularly entering a “flow” state.

But that happiness and fulfillment comes from doing different work — solving harder problems, designing better systems, focusing on what matters instead of typing boilerplate.

Are the developers struggling? Those treating AI as a threat to resist or ignoring it entirely. Are the developers thriving? Those who recognize AI as a tool amplifying their capabilities while maintaining the judgment, creativity, and architectural thinking only humans provide.

We’re Not Ready (And That’s Okay)
67% of respondents predict developer velocity and productivity will increase by at least 25% in 2026 due to AI coding adoption. That’s not gradual improvement, that’s structural transformation.

Yet only 20% of teams report tracking the impact of AI coding tools using engineering metrics or software engineering intelligence platforms. We’re deploying transformative technology without measuring its real impact.

46.4% of respondents expect burnout rates to rise, with only 21.3% predicting a decrease, a warning sign amid accelerated AI adoption. Higher productivity expectations without corresponding organizational changes create a recipe for burnout.

The tech industry stands at an inflexion point. The technology works. The productivity gains are real. The cost savings are measurable. But organizational adaptation, skill development, governance frameworks, and cultural changes lag.

My Prediction: The Next Three Weeks
I stopped writing for three weeks because I knew the landscape would shift dramatically. It did. And in the next three weeks? Here’s what I expect:

At least two major companies will announce AI coding contributing to 50%+ of their codebase
A significant security breach will be traced to unreviewed AI-generated code, triggering industry-wide governance discussions.
Junior developer hiring will notably slow down more at major tech companies as AI handles entry-level work.
A breakout AI coding tool will achieve viral adoption by solving a problem current tools miss
At least one major enterprise will publicly share data proving AI coding delivers 5X ROI or better.
More importantly, thousands of development teams will cross the threshold where AI-assisted coding becomes their default, not their experiment. The tipping point approaches where not using AI is the notable choice, not using it.

Where I Stand After Three Weeks
I came back to writing because I realized: staying silent isn’t neutral. The transformation is happening whether we document it or not, whether we understand it or not, whether we’re ready or not.

After years of experimentation, 2026 is shaping up to be the year AI evolves from instrument to partner, transforming how we work, create, and solve problems.

The developers, teams, and companies that understand this shift and adapt their workflows, develop new skills, and thoughtfully integrate AI while maintaining human judgment will build the next decade of software.

Those treating this as hype to ignore or resist will find themselves increasingly irrelevant.

I spent three weeks watching the industry transform. The question isn’t whether AI is reshaping software development; it manifestly is. The question is: what are you doing about it?

The future of software development isn’t coming. It’s here. It arrived while I wasn’t writing. And it’s more profound, more practical, and more immediate than anyone predicted.

Now get back to building. The competition isn’t sleeping. And neither is their AI.

Google Is Killing Gemini CLI on June 18. Here Is What to Do Before Then

Laurina Ayarah — Sun, 24 May 2026 19:42:09 +0000

This is a submission for the Google I/O Writing Challenge

If you have been using Gemini CLI to run agentic tasks from your terminal, you have until June 18, 2026 to migrate. After that date, requests stop being served for Google AI Pro, Ultra, and free-tier users. No warnings. No grace period. Just errors.

That deadline is the most important thing to come out of Google I/O 2026 that most developers are not talking about. Everyone is writing about Gemini 3.5 Flash benchmarks and the Antigravity desktop app. Meanwhile, a large chunk of the developer community is sitting on a tool that is about to break their workflows.

So let us talk about what Antigravity 2.0 actually is, what changed, and what you need to do before June 18.

What Google Actually Announced

At I/O 2026, Google announced Antigravity 2.0 as a full agent-first development platform. It ships in four parts:

Antigravity 2.0 : a rebuilt desktop app
Antigravity CLI : a Go-based terminal tool (the Gemini CLI replacement)
Antigravity SDK : for building custom workflows
Managed Agents API : spins up an autonomous agent with a single API call

The headline for most people was the desktop app and the new Gemini 3.5 Flash model powering it. The headline that actually matters for your day-to-day workflow is the CLI transition.

Google's reasoning makes sense when you read it plainly. Gemini CLI was built for single-agent, terminal-based tasks. But developer workflows have shifted. You now need multiple agents communicating with each other, splitting work across a unified backend. Gemini CLI was not built for that. Antigravity CLI is.

What Actually Changed

The Binary

Gemini CLI ran as gemini. Antigravity CLI runs as agy. That is not just a rename. The entire thing was rewritten in Go, which means no runtime dependencies and noticeably faster response times.

If you have Gemini CLI invocations sitting in shell scripts, GitHub Actions, or Dockerfiles, every single one of those needs to be updated. For most cases it is a straightforward find-and-replace, but Dockerfiles with GEMINI.md references need explicit file mapping.

The Config Files

This is where the real migration work lives.

Old (Gemini CLI)	New (Antigravity CLI)
`GEMINI.md`	`AGENTS.md`
`.gemini/skills/`	`.agents/skills/`

Your project config and your skills both move. The good news is that both binaries can coexist on the same machine during the migration window. gemini and agy run separately with separate config trees and separate auth flows. You can keep running gemini on specific tasks until June 18 while you test the migration on others.

The Architecture Shift

The biggest actual change is how Antigravity CLI handles complex tasks. Gemini CLI locked up your terminal session while it worked. Antigravity CLI uses an asynchronous background processing model. You can kick off a large-scale refactor or a multi-source research task and your terminal stays free.

Multiple agents run in parallel, with the practical ceiling sitting at around four or five before performance starts to degrade. The multi-agent system is configured through AGENTS.md, a markdown file where you define agent roles, communication patterns, and orchestration rules in plain text. If you have used Claude Code, you will recognize the pattern immediately. It works similarly to CLAUDE.md. No complex orchestration code, Just markdown.

The SKILL.md System Is the Part Worth Getting Excited About

This is getting buried under the broader Antigravity coverage, so I want to spend real time on it.

In Antigravity, a Skill is a directory-based package. Each skill contains a SKILL.md file and optional supporting assets like scripts and templates. The design is intentionally simple: markdown and YAML, formats every developer already knows.

Here is what a basic skill structure looks like:

.agents/skills/
└── my-skill/
    ├── SKILL.md        # Instructions and rules
    └── scripts/
        └── run.sh      # Optional supporting script

What makes this powerful is the distinction between Skills and Rules. Rules in Antigravity are persistent. They are always on, functioning like a system prompt that applies to everything the agent does. Skills are on-demand. They only load when triggered, which means you can build specialized capability extensions without bloating every single agent interaction.

Think about what this means practically. You can define a skill for how you want your API routes structured, one for your testing conventions, another for your deployment checks. The agent loads the relevant ones when it needs them. Your AGENTS.md defines the team. Your skills define how each agent does its job.

For a frontend developer, this is a real productivity shift. You are not re-explaining your conventions to an AI every session. You write them once in markdown, put them in .agents/skills/, and the agent follows them consistently across every project that uses that skill.

Who Is Actually Affected and What to Do

Free and Google AI Pro/Ultra users: You must migrate before June 18. This is mandatory. Start now.

Enterprise users on Gemini Code Assist Standard or Enterprise licenses: Your access remains unchanged. Migrate when it suits you.

Enterprise Gemini Code Assist for GitHub: Same deadline applies. No new installations on GitHub organizations after June 18, and requests stop being served in the weeks following.

The migration itself is not complicated. Google estimates it takes under ten minutes for most setups. Here are the steps that actually matter:

# 1. Install Antigravity CLI
# Follow instructions at antigravity.google

# 2. Import your existing plugins
agy plugin import gemini

# 3. Rename your config file
mv GEMINI.md AGENTS.md

# 4. Move your skills directory
mv .gemini/skills/ .agents/skills/

# 5. Update CI/CD scripts
# Find and replace 'gemini' with 'agy' across your shell scripts and workflows

Then test one real workflow before you close out Gemini CLI entirely. That is the step most people skip, and it is the most important one.

One real frustration worth flagging: the /usage command in Antigravity CLI only updates after you quit and reload, not live. Developers have reported running out of quota mid-task with no warning during long agentic workflows. Google has acknowledged this as a known issue with no fix date. If you are running tasks that go longer than twenty to thirty minutes, keep that in mind and plan accordingly.

My Take

Antigravity 2.0 is a real product shift, not a rebrand. The move from single-agent to multi-agent, the asynchronous architecture, the Go rewrite, the AGENTS.md configuration system, these are meaningful changes that reflect how serious Google is about owning the agentic development space.

The SKILL.md system in particular has the kind of depth that takes a few sessions to fully appreciate. The separation between persistent rules and on-demand skills is a thoughtful design decision that does not get enough attention.

That said, this migration is mandatory and the community reaction has been honest. Plenty of developers on GitHub explicitly preferred Gemini CLI and wanted it to stay. The plugin ecosystem in Antigravity CLI is still maturing, and the live quota tracking issue is a real operational gap. Antigravity CLI is not feature-equivalent to Gemini CLI on day one, and Google should say that more plainly than it has.

What matters most is this: if you wait until June 18 to start, you are setting yourself up for a bad day. The migration is short. The rollback is free until the deadline. Run one real task through agy this week and see where things break. That is the only way to know what your specific workflow actually needs.

The June 18 deadline is not a recommendation. Set the reminder now.

I am Tobore, a full-stack developer and Best Author on DEV for React writing. I built the Delta State Health Information System and I write about tools that actually change how developers work. Find more at dev.to/toboreeee.

[Boost]

Laurina Ayarah — Sat, 21 Mar 2026 06:21:07 +0000

Laurina Ayarah

Nov 1 '25

It’s almost 2026: Why Are We Still Arguing About CSS vs Tailwind

#webdev #programming #tailwindcss #productivity

7 min read

Why Is the Tech Job Market So Brutal Right Now? (An Honest Look at What Changed)

Laurina Ayarah — Wed, 21 Jan 2026 20:22:23 +0000

I need to tell you something nobody wants to admit.
The "learn to code and get a high-paying remote job" dream? It's not dead, but it's definitely on life support.

And if you're sitting there wondering why you've sent 200 applications and gotten 3 responses (all rejections), or why that coding bootcamp certificate isn't opening doors as they promised, or why companies want "entry-level developers with 3 years of experience", you're not crazy.

The game changed and most people are still playing by the old rules.
I'm writing this because I'm in it too. I'm watching friends with Computer Science degrees struggle to get interviews. I'm seeing talented developers give up after months of silence. I'm experiencing firsthand how brutal this market has become.

This isn't a success story. This isn't "10 tips to land your dream job." This is an honest look at what the hell happened to the tech job market, and what might actually help if you're trying to break in right now.

Remember When "Learn to Code" Was the Answer to Everything?

2020 was a different world.
Tech companies were hiring like crazy. Remote work exploded. Everyone and their uncle was starting a SaaS company. VC money was flowing like water. Bootcamps were popping up everywhere, promising six-figure salaries after 12 weeks of training.
The narrative was simple: "Tech is the future. Learn to code. Get a remote job. Make $100k. Work from anywhere."
And for a while? It was kind of true.
Companies were desperate for developers. They'd hire bootcamp grads. They'd take chances on self-taught developers with decent portfolios. Junior positions actually existed. "Entry-level" meant entry-level.
Fast forward to 2026, and it's like someone flipped a switch.

Now you see job postings like:

"Junior Developer (3–5 years experience required)"
"Entry-level position (must be proficient in React, TypeScript, Node.js, AWS, Docker, Kubernetes…)"
"Hiring freeze until further notice"
Or worse, no postings at all.

What happened?

The Perfect Storm: Why Everything Changed at Once

This isn't just one thing. It's everything hitting at the same time.

The Money Dried Up (And Tech Companies Panicked)

Let's start with the big one: money.

For years, tech companies were running on cheap money. Interest rates were near zero. Investors were throwing cash at anything with "AI" or "blockchain" in the pitch deck. Growth was everything. Profitability? Who cares, we'll figure that out later.

Then 2022–2023 happened. Interest rates shot up. Suddenly, that free-flowing VC money became expensive. Investors started asking uncomfortable questions like "When will you actually make money?"

And tech companies responded by doing what they do best when they panic: mass layoffs.
Google laid off 12,000 people. Meta cut 21,000 jobs. Amazon let go of 27,000 employees. Microsoft, Twitter, Salesforce, Stripe, the list goes on. We're talking about hundreds of thousands of experienced tech workers suddenly looking for jobs.

Now imagine you're a junior developer competing against someone who just got laid off from Google with 5 years of experience. Who do you think companies are hiring?

Yeah.

AI Became the Excuse for Everything

Then there's the AI elephant in the room.
ChatGPT launched in November 2022, and suddenly, every CEO decided they could do more with fewer people. Not because AI actually replaced developers (it hasn't), but because it gave them the perfect excuse to cut hiring.

"AI will handle the simple tasks." "We need fewer junior developers now." "AI makes our senior developers more productive."

And you know what? Some of that is true. GitHub Copilot can write boilerplate code. ChatGPT can debug basic errors. AI tools are genuinely making certain tasks faster.

But here's what they're not telling you: AI still needs humans to guide it, review it, and fix its mistakes. The technology isn't replacing developers, it's changing what skills matter.

The problem is companies are using AI as justification to not hire, not train, and not invest in junior talent. They're looking at the hype and making decisions based on fear and cost-cutting, not reality.

Everyone Learned to Code (At the Same Time)

Remember the pandemic?
Everyone was stuck at home. Everyone was anxious about job security. And everyone heard the same advice: "Learn to code!"
Bootcamps exploded. Online courses had record enrollments. YouTube tutorials went viral. Millions of people started learning web development, data science, and software engineering.

Which sounds great for inclusion and accessibility. And it is! More people having tech skills is genuinely good.

But it also means the market is now flooded with junior developers who all have:

The same bootcamp certificates
The same portfolio projects (to-do apps, weather apps, Netflix clones)
The same GitHub with tutorial code
No real work experience

When 100 junior developers were competing for 50 jobs, you had a decent shot. When there are 10,000 competing for 5 jobs? The math just doesn't work.

And companies responded by raising the bar. Why hire someone with 6 months of bootcamp training when you can hire someone with a CS degree and internship experience? Why take a chance on a self-taught developer when you have laid-off senior developers willing to take junior salaries?

The supply-demand equation broke.

The "Entry-Level Experience" Paradox Got Worse

You've seen it. We've all seen it.

"Entry-level position. Requirements: 3–5 years of professional experience."

This has always been frustrating, but it's gotten exponentially worse. Companies are genuinely posting junior roles with senior requirements because they can. The market is so saturated that they can afford to be unrealistic.

They want someone who can start contributing from day one. No training period. No onboarding costs. Just plug and play.
Which would be fine if there were also actual entry-level roles for people to get that first year or two of experience. But those positions have largely disappeared.

Internships are more competitive than ever. Junior roles get hundreds of applications. Companies aren't investing in training programs like they used to.

It's a catch-22: Can't get experience without a job, can't get a job without experience. And the gap keeps widening.

Remote Work Became a Double-Edged Sword

The pandemic normalised remote work, which seemed like a huge win for developers. Work from anywhere! No geographic limitations! Access to global opportunities!
Except it works both ways.

Now you're not just competing with developers in your city or country. You're competing with developers globally. That remote job at a US company? You're competing with candidates from India, the Philippines, Eastern Europe, Latin America, and everywhere else.

And many companies discovered they can hire senior developers from countries with lower costs of living for the same price they'd pay a junior developer in expensive markets.

Why hire a junior developer in San Francisco when you can hire a senior developer in Nigeria or Poland for less?

Plus, many companies started pulling back on remote work entirely. "Return to office" mandates cut the number of truly remote positions. Even "remote" jobs often have geographic restrictions now.

The advantage remote work promised to international developers? It's being eroded by these same market forces.

The Africa-Specific Layer (Because Location Still Matters)

If you're in Africa; Nigeria, Kenya, Ghana, South Africa, anywhere on the continent, you're dealing with all of the above plus some extra challenges.

The Infrastructure Tax

Let's be real: reliable power and internet aren't guaranteed. And for remote tech work, they're non-negotiable.
You might be the best developer in the room, but if your internet cuts out during a client call, or you can't meet deadlines because power has been out for 8 hours, that's a problem.
International clients worry about this. They've heard the stories. They've had bad experiences. And unfortunately, you pay the "trust tax" for it even if your personal setup is solid.

Payment Platform Restrictions

Stripe doesn't work in Nigeria. PayPal is limited. Payoneer has fees. Wise has restrictions.

Getting paid as a freelancer or contractor is genuinely harder from Africa. And many international companies don't want to deal with the complexity.

"We only hire contractors who can invoice through Stripe" eliminates you before the conversation even starts.

Currency Devaluation Pressure

The naira has lost significant value. The cedi is struggling. Many African currencies are under pressure.
Which means two things:

Local salaries can't keep up with inflation. That ₦200,000/month job from last year is worth significantly less today.
Dollar-paying remote jobs become even more competitive. Everyone wants to earn in dollars or euros, which makes those positions brutally competitive.

You're not just competing for jobs, you're competing for economic survival.

The Local Market Maturity Gap

The African tech market is growing, but it remains immature in most places.
There are fewer tech companies. The startups that exist are struggling to raise funding. Corporate digital transformation is slow. Many businesses still don't see tech as essential or they want it done as cheaply as possible.

"My cousin can build a website for ₦30,000" is still a common response.
This means fewer local opportunities, increased competition for international remote work, and pressure to undervalue your skills just to gain experience.

The Time Zone Challenge

Most high-paying tech jobs are in the US or European time zones. Which means:

Interview scheduling is complicated
Real-time collaboration is difficult
You might need to work odd hours
Asynchronous communication becomes critical

Some companies love hiring in different time zones for round-the-clock coverage. Others see it as a dealbreaker. And you can't always tell which one you're dealing with until you're deep in the process.

Why Entry-Level Developers Got Hit Hardest

Here's the uncomfortable truth: when companies tighten budgets, junior developers are the first to go.

Training Is Expensive

Junior developers need mentoring. Code reviews. Guidance. Time to ramp up. Senior developers need to spend time teaching instead of shipping features.
When companies are focused on efficiency and cutting costs, training programs get axed. Junior positions get eliminated. They'd rather hire one senior developer who can work independently than two juniors who need support.

AI Took the "Learning Tasks"

A lot of what junior developers used to do, writing basic CRUD operations, fixing simple bugs, writing tests, and updating documentation, can now be partially automated by AI tools.
Not completely. Not perfectly. But enough that companies think "we can have our senior devs use AI for this instead of hiring juniors to do it."
Which means the tasks that used to be learning opportunities for junior developers are disappearing. And with them, the justification for junior roles.

Risk Aversion in Uncertain Times

When the market is good, companies take chances. They hire promising juniors. They invest in potential.
When the market is uncertain, they play it safe. They want proven skills. Immediate impact. No risk.
Junior developers, by definition, are a risk. You might be great. You might struggle. You need time to prove yourself.
In this market, companies don't want to take that risk.

The Skills Paradox: Everyone Has the Same Resume

Here's something I've noticed: most developer portfolios look identical.
Same projects: To-do app. Weather app. E-commerce clone. Netflix clone.
Same skills listed: HTML, CSS, JavaScript, React, Node.js, MongoDB.
Same GitHub: Full of tutorial code and incomplete projects.
Same about section: "Passionate developer eager to learn and grow."
When everyone has the same skills and the same projects, how do you stand out?
You don't. You're just another resume in a pile of 500.
The baseline skills that used to be impressive (knowing React, building a portfolio site, having a GitHub) are now just… expected. They're not differentiators anymore. They're table stakes.
And this creates a problem: what used to get you hired now just gets you in the door. And the door is crowded.

What Companies Are Actually Looking For (Hint: It's Changed)

From what I've learned and noticed, the job requirements haven't just gotten harder; they've gotten different.

They Want Specialists, Not Generalists

"Full-stack developer" used to be impressive. Now it's generic.
Companies want depth, not breadth. They want someone exceptional at one thing, not mediocre at everything.
"Expert in React performance optimisation" is more valuable than "knows React, Vue, Angular, and Svelte."
"Specialised in building accessible UIs" beats "can do frontend and backend and mobile and…"

They Want Proof, Not Potential

"I'm eager to learn" doesn't cut it anymore.
They want: "Here's a live product I built that 500 people use."
They want: "I contributed to this open-source project and got my PRs merged."
They want: "Here's my technical blog with 10,000 readers where I explain complex concepts."
Potential is cheap. Everyone has potential. Proof is expensive and rare.

They Want Communication Skills (More Than Ever)

With remote work and distributed teams, communication isn't just nice to have; it's essential.
Can you write clear documentation? Can you explain technical concepts to non-technical stakeholders? Can you collaborate asynchronously across time zones?
Technical skills might get you the interview. Communication skills get you the job.

They Want People Who Can Work Independently

Hand-holding is expensive. Training is expensive. Constant questions are expensive.

They want developers who can:

Figure things out independently
Ask good questions when stuck
Manage their own time and priorities
Ship features without constant oversight

Which, again, disadvantages junior developers who are still learning these skills.

What Might Actually Help (No BS, Just Honest Strategies)
I can't promise these will get you a job. The market is tough, and sometimes it's just bad luck or bad timing.
But here's what seems to be working for people who are breaking through:
1. Go Niche (Really Niche)
Stop being "a frontend developer." Start being "the developer who builds e-commerce sites for Nigerian fashion brands" or "the specialist in making government websites accessible."
Niching feels scary because you think you're limiting opportunities. But you're actually making yourself more visible to a specific group that needs exactly what you do.
2. Build in Public
Document your learning. Share your projects. Write about what you're building and why.
Not for clout. Not to go viral. But to create a paper trail that shows:
You actually ship things
You can explain your thinking
You're consistently learning and improving

This is more impressive than any portfolio.
3. Contribute to Real Open Source (Not Just Beginner-Friendly Repos)
Everyone knows the "find an issue labelled 'good first issue'" advice.
Go deeper. Find a project you actually use. Spend a month understanding the codebase. Then make a meaningful contribution.
One substantial PR to a real project is worth more than 20 tiny contributions to "beginner-friendly" repos.
4. Solve Actual Problems (Not Tutorial Problems)
Build something someone actually needs. Even if it's just your friend's small business website or a tool for your local community.
"I built a booking system for my uncle's barbershop that handles 50 appointments a week" is infinitely more interesting than "I built a Netflix clone following a YouTube tutorial."
Real problems have constraints, edge cases, and users. Tutorial problems don't.
5. Network Locally (Not Just Online)
Twitter applications disappear into the void. LinkedIn cold messages get ignored.
But showing up to local tech meetups, developer communities, and startup events? That creates relationships.
Most jobs come from referrals. Referrals come from people who actually know you. And people get to know you in person or through sustained online relationships, not from a cold email.
6. Add Adjacent Skills
Pure coding skills are commoditized. Coding + something else is valuable.
Developer + designer = rare and valuable
Developer + writer = technical writing opportunities
Developer + domain expertise (healthcare, finance, education) = specialized roles
Developer + data analysis = product-focused roles

Don't just be another developer. Be a developer who brings something extra.
7. Be Realistic About Timeline
This sucks to hear, but it might take longer than you thought.
Not because you're not good enough. Not because you're doing something wrong. But because the market is genuinely tough right now.
Six months of job searching is becoming normal for junior developers. A year isn't unheard of.
That doesn't mean give up. It means adjust expectations and plan accordingly. Keep learning. Keep building. Keep applying. But also keep your day job or freelance income flowing because this might take a while.

8. Consider Alternative Entry Points
If direct-hire developer roles aren't working:
Freelancing (smaller projects to build experience and income)
Contract work (temp roles that might convert to permanent)
Agencies often hire more junior devs than product companies.
Startups (more willing to take chances, though often lower pay)
Adjacent roles (QA, technical support, technical writing) that get you in the door

These aren't failures. They're strategic entry points that build experience and connections.

The Uncomfortable Truth Nobody Wants to Say

The "learn to code = guaranteed job" narrative was oversold.
Not because coding isn't valuable. It is.

But because the market changed faster than the narrative did. The promise was made when the market was hot. Now it's cold. And people are still making decisions based on old information.
Does that mean learning to code was a waste of time? No.
Does it mean everyone who learns to code will get a high-paying tech job? Also no.

The truth is messier: tech skills are valuable, but they're not a guaranteed meal ticket anymore. The market is oversaturated at the entry level, undersupplied at specialist levels, and in flux everywhere else.

Some people will break through quickly. Others will struggle for months. Some will need to pivot or add skills. Others will find success in unexpected places.
There's no one path anymore. And anyone selling you a guaranteed path is lying.

What Happens Next? (Looking Forward)

The market will shift again. It always does.
AI will stabilize from hype to reality. Companies will realize they actually do need developers (just different kinds). The economic cycle will turn. New technologies will create new opportunities.
But when? How? Nobody knows.
What we do know:

Junior positions will probably stay rare for a while. Companies are prioritizing experienced hires.
Specialization will matter more. Being good at one thing beats being okay at everything.
Non-technical skills will differentiate. Communication, problem-solving, business understanding, these separate good developers from great ones.
Alternative paths will become more common. Fewer people will go straight from boot camp to a full-time dev job. More will freelance, contract, contribute to open source, or enter through adjacent roles.
The African opportunity is still there, but it requires different strategies. Building for local markets, solving local problems, and creating products for African users might be more sustainable than competing for international remote roles.

Final Thoughts: You're Not Crazy, the Market Is

If you're struggling to get a tech job right now, it's not because you're not good enough.

It's because you're entering the market at one of the hardest times in recent tech history.

Layoffs. AI hype. Market saturation. Economic uncertainty. Everything hit at once.
That doesn't make it easier. But maybe it makes it less personal.

You're not failing. You're navigating a genuinely difficult situation that's affecting thousands of talented people.
Keep building. Keep learning. Keep applying. But also be kind to yourself. The market is brutal right now, and that's not your fault.

Some of you will break through next month. Some will take a year. Some will find success in unexpected directions.
But if you're still in the game, still learning, still trying, you're doing better than you think.
The tech job market is brutal right now.
But it's not forever.

And knowing what you're actually up against? That's the first step to figuring out how to navigate it.

If this resonated with you, share it with other developers who need to hear this. We're all figuring this out together.

What's your experience with the current tech job market? Drop your story in the comments, let's talk about what's really happening out there.

What Clients ACTUALLY Want From Frontend Devs (Not Clean Code)

Laurina Ayarah — Sat, 10 Jan 2026 13:24:46 +0000

Clean code doesn't get you hired. This does.

I learned this the hard way.
I spent years obsessing over best practices. Learning the latest frameworks. Writing DRY code. Organizing my files perfectly. Following every convention I could find.
Then I started working with real clients, and none of that mattered as much as I thought it would.
Don't get me wrong, technical skills matter. But they're just the baseline. The entry ticket. What actually determines whether clients hire you again, refer you to others, or leave you great reviews?

It's everything else.

The stuff nobody talks about in developer forums or YouTube tutorials. The soft skills. The business understanding. The communication. The things that have nothing to do with JavaScript but everything to do with getting paid.
Let me break down what clients actually care about, from someone who's been learning this in real time.

They Want to Understand What You're Doing (In Plain English)

Picture this: A client asks you to add a feature to their website. You dive into the code, implement it beautifully, and send them a message:
"I've refactored the component architecture and implemented a custom hook for state management. The API calls are now memoized for better performance, and I've added proper error boundaries."
The client reads this and thinks, "What did any of that mean? Did you actually do what I asked?"

Here's the thing: most clients aren't technical. They don't know what React hooks are. They don't care about your component architecture. They just want to know: "Did you add the feature? Does it work? When can I see it?"
Technical jargon makes you sound smart to other developers. To clients, it sounds like you're either showing off or hiding something.

What they actually want to hear:
"Yes, I added the contact form as you requested. It now collects name, email, and message, and sends everything to your inbox. I also added validation so people can't submit blank forms. You can test it here: [link]"

Simple. Clear. Actionable.

Save the technical details for your documentation or when they specifically ask. In regular communication, speak like a human talking to another human, not a developer talking to a code review bot.

They Want Honesty More Than They Want "Yes"

Clients will ask for things that are:
Technically possible but extremely time-consuming
Bad ideas that will hurt their website
Features that already exist, but they don't know how to use them
Completely outside the original scope

Your instinct might be to just say "yes" to everything. Keep the client happy. Don't rock the boat.
But here's what I've learned: clients respect honesty more than they respect compliance.

If a client asks you to add 17 different animations to their homepage because "it needs to pop," you could just do it. Spend hours implementing animations that will make the site slower, harder to maintain and honestly, kind of annoying to use.

Or you could say:
"I can definitely add animations, but I want to make sure we're using them strategically. Too many animations can actually slow down the site and distract from your main message. What if we focus on 2–3 key areas where animation would really enhance the user experience? That way, we get impact without overwhelming visitors."

Notice what happened there:

You didn't just say "no"
You explained why their idea might not work
You offered an alternative solution
You positioned yourself as someone who cares about their success, not just about getting paid

Clients who just want you to do whatever they say without question usually aren't great anyway. The good ones appreciate when you push back respectfully and offer better solutions.
You're not just a code executor. You're a consultant. Act like it.

They Want to See Progress (Not Just the Final Product)

This is huge, and so many developers get it wrong.

You take on a project. You estimate it'll take two weeks. The client agrees. You go silent for 13 days, work frantically to finish, then deliver everything on day 14.

From your perspective, you did exactly what you promised. You delivered on time.

From the client's perspective, you disappeared for almost two weeks, and they had no idea if you were even working on it. They were stressed. Wondering if you ghosted them. Questioning whether they should follow up or wait.

Even if you deliver great work, that anxiety sours the experience.
What clients actually want: regular updates.
Even if there's nothing major to report, just send a quick message:

"Hey! Quick update: I've finished the homepage layout and navigation. Working on the contact form now. Should have that done by tomorrow. Everything's on track."

That's it. 30 seconds to write. But it completely changes the client experience.
They're no longer anxious. They can see progress. They know you're working. They feel involved.

And when the project wraps up, they remember how smooth and stress-free it was, even if there were bumps along the way.

They Want Problems Solved Before They Become Disasters

Clients don't know what they don't know.
They'll ask you to build a website and forget to mention that they need:

A way to update content themselves
Mobile optimization
Fast loading times
Contact forms that actually work
Security measures
Backup systems

They assume all of this is just… included. Because they don't understand that these are separate considerations.

If you just build what they ask for and nothing else, they'll launch the site, realize it doesn't work on mobile, and blame you.

"Why didn't you tell me it wouldn't work on phones?"
"You didn't ask for mobile optimization."
"I didn't know I had to ask!"

And now you have an unhappy client, even though technically you did what they asked.

This is where good developers separate from great ones.
Great developers anticipate problems and address them proactively:

"Hey, just a heads up, I noticed you didn't mention mobile optimization in the requirements. These days, about 70% of web traffic comes from phones, so I'd strongly recommend we make sure the site works well on mobile. I can include that in the project if you'd like."

Now you've:

Shown expertise
Prevented a future problem
Potentially increased the project scope (and your pay)
Positioned yourself as someone who cares about their success

Clients remember this. They tell other people about developers who "just get it" and save them from mistakes they didn't even know they were about to make.

They Want Fast Responses (Even If You Don't Have Fast Solutions)

You know what kills client relationships faster than anything?

Going silent.

A client sends you a message. You see it. But you're in the middle of debugging something, so you think, "I'll respond when I'm done."
Three hours later, you're still debugging. You forget to respond.
The next day, the client follows up: "Hey, did you see my message?"

Now they're annoyed. Not because you couldn't solve their problem immediately, but because you made them wonder if you even saw their message.

Here's the fix: acknowledge immediately, solve later.
Client: "Hey, the contact form isn't working. Can you check it?"
You (immediately): "Just saw this! Looking into it now. I'll get back to you within the hour with an update."
That's it. 10 seconds to write. But the client knows:

You saw their message
You're working on it
They can expect an update soon

Even if the fix takes 3 hours, they're not anxious because you communicated.
Fast responses don't mean fast solutions. They just mean you're present and engaged.

They Want to Feel Like Their Project Matters

Most developers are juggling multiple projects. Maybe you're working on 3–4 sites at once. That's normal.
But clients don't care about your other projects. They care about theirs.

If a client asks about the timeline and you say, "I'm working on a few other projects right now, so it might take longer," they hear: "Your project isn't my priority."

Even if that's not what you meant.

Instead, say: "I'm committed to delivering quality work on your site. Based on the scope, I estimate it'll take about two weeks. I'll keep you updated on progress throughout."

See the difference?
The first response makes them feel like an afterthought. The second makes them feel like you're dedicated to their success.

Small language shifts. Big perception difference.

They Want Reasonable Pricing (Not Necessarily Cheap Pricing)

Here's a mistake I see a lot: developers pricing themselves based on what they think clients want to pay, not what the work is actually worth.

"I'll just charge $100 for this website so I can get the client."

Then you spend 40 hours on the project. That's $2.50 per hour. You're working skilled labour for unskilled wages.

And here's the kicker: the client doesn't even appreciate the low price. They either think:

The work must not be very good if it's that cheap
Or they take advantage and ask for endless revisions because "it's not that expensive anyway"

Cheap pricing attracts cheap clients.

What clients actually want is reasonable pricing for the value they're getting.

If you build them a website that helps them get more customers, make more sales, and grow their business, that's worth way more than $100.

Price based on value, not hours.

And when a client says, "That's too expensive," don't immediately drop your price. Ask questions:

"What's your budget for this project?"
"What results are you hoping the website will bring?"
"What happens if you don't have a professional website?"

Sometimes they genuinely can't afford you, and that's fine.
Not every client is a fit.

But often, they just need to understand why it costs what it costs. And once they see the value, price becomes less of an issue.

They Want Someone Who Takes Ownership

Clients don't want to micromanage you. They want to trust that you've got it handled.

That means:

If something breaks, you fix it (or let them know immediately)
If you spot a problem, you address it
If there's a better way to do something, you suggest it
If you make a mistake, you own it and correct it

Clients aren't looking for perfection. They're looking for responsibility.

I've seen developers lose clients not because they made mistakes, but because they made excuses.

"The hosting is slow, that's why the site is slow." "The images you sent were too big, that's why they don't load." "You didn't tell me you needed that feature, so I didn't build it."

Maybe all of that is technically true. But it sounds like you're deflecting blame instead of solving problems.
Compare that to:

"The site is loading slower than I'd like. I'm going to optimize the images and look into the hosting to see if we need an upgrade. I'll have an update for you tomorrow."

Same situation. Completely different response.

One makes the client feel like you're pointing fingers. The other makes them feel like you're handling it.

They Want to Trust You

At the end of the day, this is what it all comes down to: trust.
Do they trust that you'll deliver what you promised? Do they trust that you'll communicate honestly? Do they trust that you care about their success, not just your paycheck?

You build trust through:

Consistent communication
Delivering on time (or early)
Being honest when something won't work
Proactively solving problems
Treating their project like it matters

Your code quality matters. Your technical skills matter.
But clients can't see your code quality. They can't evaluate your technical skills.
What they can see is how you make them feel throughout the process.

And that's what determines whether they hire you again. Whether they refer you to others. Whether they leave you a great review or testimonial.

Final Thoughts: Be a Developer Clients Actually Want to Work With

Thousands of developers can write clean code.
There are far fewer who can write clean code and communicate well and understand business needs and make clients feel confident and stress-free throughout the process.

That's the space you want to occupy.

Because when you do, clients stop shopping around for the cheapest developer. They stop comparing you to 10 other people.

They just hire you. And they keep hiring you.

Not because your code is the best (though it should be good).

But because working with you is easy. And in a world where most developer-client relationships are full of miscommunication, missed deadlines, and frustration, "easy" is incredibly valuable.

Be the developer who gets it.
Be the one who communicates clearly, solves problems proactively, and treats every project like it matters.

Your technical skills will get you in the door.
Everything else will keep you in the room.

What’s your experience with client communication?
Drop your stories in the comments 👇

If this helped you, save it for later, like and share with a dev friend who needs to hear this!

Originally published on Medium.