DEV Community: Zonayed Ahmed

Are we software engineers doomed? Yes, because of AI!

Zonayed Ahmed — Tue, 15 Sep 2026 04:22:14 +0000

Companies have stopped hiring, and layoffs have become more and more common. Job postings are rarely found. New types of roles are appearing and disappearing so fast that it is now nearly impossible to get experienced in something and then get that job. Even if you prepare for a role, by the time you finish preparing, that position might also be gone.

And also, let's be real, there is no denying the AI advancement happening right now. Claude Fable 5 and GPT 6 Astra are doing great. They are capable of handling so many things with less effort. And they will get even better after a few months, more powerful than they are now. And things will only get worse.

You might be thinking of moving into some other role, maybe becoming an architect, moving into system design, management, or something that requires more decision-making. But eventually, those things will also get replaced or covered by AI sooner than we can even realize.

Thinking of taking more responsibility or ownership? Yeah, maybe that helps for a while. But what if one person becomes enough to handle an entire side of a company that previously needed 100, 500, or even 1,000 people? AI could make one person capable of handling a huge amount of responsibility, decision making, planning, implementation, and coordination. So even the "just move up the ladder" idea does not feel completely safe anymore.

I have spent almost 16 years in this software development field, got a computer science degree, and after all of this, this happened. It seems like my entire life got ruined. I think most of you people might also be feeling the same.

Anthropic, on one side, is warning that in the worst case scenario, software engineers might have to move towards fields like nursing or becoming electricians. And the speed of advancement happening here is quite unprecedented.

Are we done? Is our entire life a waste, then?

What do you think? I want to know your thoughts. I want to live up to the reality.

Build APIs from Any Data, Without Running a Backend Every Time

Zonayed Ahmed — Thu, 21 May 2026 13:31:39 +0000

A lot of app data is already somewhere.

Maybe it is in another API.

Maybe it is in a CMS.

Maybe it is in a spreadsheet.

Maybe it is in GitHub.

Maybe it is in your docs, product data, changelog, config files, or some internal service.

But your app still needs one clean API endpoint.

So what do we usually do?

We build a backend.

The backend fetches data from one or more sources, reshapes the response, removes the fields we do not need, maybe combines it with another source, and finally returns a clean API response to the frontend.

That makes sense when the data is always changing.

But many times, it is not.

Sometimes the source API is slow.

Sometimes it has rate limits.

Sometimes the response time is unpredictable.

Sometimes the same data is requested again and again.

Sometimes the data only changes when a webhook fires, a file changes, a release happens, or someone updates content.

And still, every request goes through runtime logic.

That is the part that kept bothering me.

Because in many cases, the API output could be prepared ahead of time.

The source data may be messy.

The final response can still be clean.

The source API may be slow.

The final API does not have to be.

The source may have rate limits.

Your users should not hit that source every time.

That is the idea behind StatikAPI OSS CLI.

GitHub:

https://github.com/zonayedpca/statikapi

The simple idea

StatikAPI is an open-source CLI for generating clean API outputs ahead of time.

The simple way to explain it:

Build APIs from your data — without running a backend on every request.

Or the shorter developer version:

Static export, but for APIs.

The bigger idea is:

Data sources → shape the response → publish a clean API output

Your data can come from files, route modules, third-party APIs, services, CMSs, docs, product data, or anything you can fetch or prepare during the build.

Then StatikAPI lets you generate the final API output ahead of time.

So instead of every user request doing this:

request → backend → fetch external API → reshape response → return data

You can move that work earlier:

source data changes → rebuild output → serve clean API response

That is the difference.

What problem this solves

Let’s say your app needs product data.

The data might come from a third-party API.

That API might be slow sometimes.

It might also return a huge response when you only need five fields.

It might have rate limits.

It might occasionally respond slower from one region and faster from another.

But your frontend does not care about all that.

Your frontend just needs:

{
  "id": "basic-plan",
  "name": "Basic Plan",
  "price": 9,
  "features": ["Public API", "Scheduled updates", "Fast delivery"]
}

If that data changes only when your product/pricing data changes, then why should every user request hit the original source again?

Maybe the better workflow is:

fetch the source data during build
shape it into the response your app actually needs
generate a clean API output
serve that prepared response fast
rebuild it when the source changes

That is the kind of workflow StatikAPI is exploring.

How the OSS CLI works

The current open-source version starts with a simple workflow:

src-api/ → build → api-out/

You define API-like route files inside src-api/.

Those route files can return prepared data, fetch from sources during build, or shape data into the API response you want.

Then StatikAPI builds the output into api-out/.

So instead of running backend code every time someone requests the endpoint, you generate the response first and serve the prepared output.

The question becomes:

Can this API response be prepared before the request happens?

If yes, StatikAPI may fit.

A small example

Imagine your app needs a changelog API.

Maybe the changelog data comes from a file, a release note, GitHub, a CMS, or another API.

The final response might look like this:

{
  "latest": "v1.0.0",
  "title": "Initial release",
  "date": "2026-05-20"
}

Does this need to be computed again and again on every request?

Maybe not.

Maybe it only needs to be rebuilt when the changelog changes.

That is the kind of API StatikAPI is built for.

Updating when needed

Static does not mean stale forever.

This is important.

The idea is not:

generate once → forget forever

The idea is:

data changes → rebuild output → publish updated API

The update can happen manually.

It can happen during a build.

It can happen through webhook-based workflows depending on how you deploy it.

So the API does not need to be live-computed on every request, but it can still be updated predictably when the data changes.

That is the balance I wanted:

fast reads
clean API output
predictable updates
less unnecessary runtime work

Standalone or Cloudflare

StatikAPI OSS CLI can work standalone.

You can generate the API outputs and decide where to serve them from.

There is also optional Cloudflare support for people who want to deploy generated API outputs closer to the edge.

The Cloudflare adapter path is useful if you want a setup where:

generated API outputs can be deployed to Cloudflare
public outputs can be served fast
updates can be triggered through webhook-based workflows
the project can still keep the “generate first, serve later” model

Cloudflare is not required.

It is an option.

The main idea stays the same:

Generate the API output first, then serve it from the place that makes sense for your project.

What kind of APIs fit this?

StatikAPI is useful when the data is mostly read-heavy and predictable.

Examples:

Third-party API data

If you depend on a slow or rate-limited API, but the data does not need to be fresh on every request, you can fetch and reshape it ahead of time.

/products
/pricing
/external-data

Docs navigation

A docs sidebar or navigation tree usually changes when docs change, not on every request.

/docs/nav
/docs/sidebar

Changelog feed

Release notes change when you publish a release.

/changelog
/releases/latest

Product catalog

Product data often changes on a schedule or when the source changes.

/products
/catalog

Public config

Frontend apps often need public config or metadata.

/config
/site-meta

Release metadata

Version, release, and build information can often be generated ahead of time.

/release
/build-info

AI-readable content

Structured API output can also be useful when tools, agents, or AI systems need clean data instead of scraping pages.

/content/feed
/knowledge-base

I am not saying StatikAPI is an AI platform.

I am saying clean structured API output can be useful for tools that need to read your content clearly.

What this is not for

StatikAPI is not for every API.

It is not for payment logic.

It is not for private user dashboards.

It is not for realtime collaboration.

It is not for mutation-heavy systems.

It is not for anything that needs to be computed uniquely for every user on every request.

Those things need a real backend.

And that is fine.

StatikAPI is for another kind of API:

APIs where the data can be prepared ahead of time and updated when needed.

Why I built it

I kept seeing the same pattern.

The backend was there.

The API existed.

But the endpoint was mostly returning predictable data.

Sometimes it was fetching from another API.

Sometimes it was combining data from multiple places.

Sometimes it was cleaning up a response that the frontend did not want to deal with.

Sometimes it was only hiding the messiness of the source data.

And still, every request had to go through runtime logic.

That felt heavier than necessary.

So I wanted to build something that treats API output more like publishable content.

Not every API response needs to be alive all the time.

Some responses can be prepared, shaped, published, cached, and updated when needed.

That is the idea behind StatikAPI.

The OSS CLI is available now

The open-source CLI is available now.

Current focus:

define API-like route files
fetch or prepare data during build
shape the response the way your app needs
generate API outputs ahead of time
serve the generated output
update when the source changes
run standalone or use optional Cloudflare deployment support

The project is still early, and I am putting it out in the open because I want feedback from real use cases.

Especially around questions like:

Does this mental model make sense?
What kind of API would you generate ahead of time?
Would this help with third-party APIs, docs, changelogs, configs, or public data?
Where does this idea break?
What would make it useful in an actual project?

Try it

GitHub:

https://github.com/zonayedpca/statikapi

The simplest idea to remember:

Data sources → clean API output → predictable updates

Or the developer version:

src-api/ → build → api-out/

Closing

I am not saying every API should become static.

That would be wrong.

I am saying many apps have API responses that are already predictable, already read-heavy, and often based on data that comes from somewhere else.

For those cases, maybe we do not need to fetch, reshape, and return the same kind of response on every request.

Maybe we can build the API output ahead of time.

That is what I am exploring with StatikAPI OSS CLI.

The hosted StatikAPI app is also being prepared, but for now the open-source CLI is available and ready for feedback.

If the idea makes sense, please check out the repo, try it, share it with someone who might find it useful, and if you think it deserves it, a GitHub star would mean a lot.

GitHub:

https://github.com/zonayedpca/statikapi

Static Export, but for APIs: Why I Built StatikAPI

Zonayed Ahmed — Sat, 16 May 2026 05:55:18 +0000

Static site generation feels normal now.

Nobody finds it strange when a website page is built ahead of time and served from a CDN as a file. In fact, for many types of websites, that is exactly what we prefer. It is faster, simpler, cheaper, and usually more predictable.

But when it comes to JSON APIs, we often behave differently.

Even when the response is already known.
Even when the data changes slowly.
Even when the endpoint is mostly just returning structured content.

We still put a runtime behind it almost by default.

That kept bothering me.

I kept seeing APIs that were doing almost nothing at request time. A docs navigation endpoint. A changelog feed. A public product catalog. Release metadata. A feature list. Public config. AI-readable content.

The response was not really being “computed” in any meaningful way on every request. The backend was mostly just standing there, breathing behind the JSON.

That felt weird to me.

At some point, the idea became very simple:

What if some APIs could be generated ahead of time, just like static pages?

That is where StatikAPI came from.

The simplest way to explain it is:

Static export, but for APIs.

The problem I kept noticing

In a lot of projects, the API is not actually as “live” as we make it look.

Sometimes it is just structured content.
Sometimes it is a list of products, docs pages, team members, feature flags, metadata, or public configuration.
Sometimes the backend exists mostly to take some source data and return it as JSON.

And yes, runtime APIs are absolutely needed for many things.

Payments need a runtime.
User-specific dashboards need a runtime.
Mutation-heavy systems need a runtime.
Anything that depends on live request-time logic probably needs a runtime.

But many endpoints are not like that.

Many endpoints are read-heavy. The data changes only when the source changes. The response shape is predictable. The work can happen earlier.

And yet we still keep a server or function alive for every request.

That means more moving parts than we need.
More latency than we need.
More things to deploy, secure, observe, debug, and pay for.

Not because the problem is always complex.

Sometimes the delivery model is just heavier than the actual problem.

That is the part I wanted to explore.

The simple idea

StatikAPI generates JSON API outputs ahead of time.

Instead of rendering HTML ahead of time, it generates JSON ahead of time.

Instead of running a function on every request, it writes the response to disk as a static JSON file.

Instead of asking a backend to recompute the same response again and again, it builds the response once and lets you serve the output directly.

The source of truth is route files inside src-api/.

Those route files map to URLs, and the build turns them into static JSON endpoints inside api-out/.

For example:

export default {
  project: 'StatikAPI',
  example: 'basic',
  timestamp: new Date().toISOString(),
  message: 'Hello from example/basic!',
};

That is the basic shape.

A route file exports JSON-serializable data. StatikAPI builds it and writes the output as a JSON endpoint.

So instead of thinking:

“I need an API server for this.”

You can ask:

“Can this response be generated before the request even happens?”

If the answer is yes, then maybe that endpoint does not need to be alive all the time.

Maybe it just needs a build step.

What StatikAPI does today

The current OSS version is intentionally direct.

I did not want the first version to be clever. I wanted the model to be obvious:

src-api/ in, JSON out.

Right now, StatikAPI can:

turn filesystem route modules into static JSON endpoints
write the generated output into api-out/
generate a manifest at .statikapi/manifest.json
run a local dev flow with watch/rebuild behavior
provide a preview UI at /_ui/
scaffold a new project through create-statikapi

The routing model is filesystem-based, so the structure feels familiar:

src-api/index.js          -> /
src-api/about.js          -> /about
src-api/users/[id].js     -> /users/:id
src-api/docs/[...slug].js -> /docs/*slug

For dynamic routes, paths() tells StatikAPI which concrete outputs to generate.

export async function paths() {
  return ['1', '2', '3', '4', '5', '6'];
}

export async function data({ params }) {
  return { id: params.id, extra: 'value' };
}

That is the part that makes the idea click for me.

The route still feels like an API route.

But the final result is not a runtime response.

It is a prebuilt JSON output.

Why this matters

I built StatikAPI for the kind of data that does not need to be recomputed on every request.

Things like:

docs and content endpoints
changelog feeds
public metadata APIs
product catalogs
generated config or manifest endpoints
feature lists
read-heavy data that changes on a schedule
build-time fetched data from another API or service
AI-readable content endpoints

For these use cases, static JSON can make a lot of sense.

The request becomes simpler.

It is not “run code, fetch data, transform data, return JSON.”

It is just:

read the already prepared JSON and serve it.

That gives you fewer runtime dependencies.
It can reduce latency.
It can make deployment simpler.
It can make the cost structure lighter.
And honestly, it just makes the system easier to reason about.

Predictability is underrated.

When an endpoint is prebuilt, you know exactly where it came from.
You know what file generated it.
You know when it changed.
You know what the output is before traffic hits it.

A request becomes a read.

Not a tiny execution environment.

What this is not for

I do not think every API should become static.

That would be a silly claim.

StatikAPI is not for highly personalized request-time logic.
It is not for payment flows.
It is not for realtime mutation-heavy systems.
It is not a replacement for every backend.

If the data needs to be computed per user, per request, or per moment, then a runtime is still the right answer.

But if the data is mostly read-only, predictable, and only changes when the source changes, then maybe the runtime is just extra weight.

That is the line I care about.

I wanted something boring, predictable, and fast for the class of APIs that can be prepared ahead of time.

Not everything needs to be alive all the time.

Why I kept pushing on this

I have been thinking a lot about static-first and edge-first systems.

Not because “edge” sounds cool.

But because many products become expensive or complicated not only because their logic is complex, but because the delivery model is heavier than it needs to be.

A lot of data is already known before the request comes in.

A lot of content is prepared earlier.

A lot of public JSON is closer to static output than live computation.

So I kept coming back to the same question:

If the response can be known earlier, why are we computing it later?

StatikAPI came from that pressure point.

Not as a grand theory.

More like a practical reaction to a pattern I kept seeing again and again.

There are plenty of places where the shape of the problem is closer to static output than runtime logic.

Docs.
Metadata.
Public feeds.
Product data.
Generated content.
AI-readable structured data.

I wanted a tool that treated that seriously.

Why I open-sourced it first

I chose open source first because this idea needs real feedback.

I do not want to hide the core behind a hosted product and ask people to trust the idea before they can inspect it.

I want developers to read the files, understand the route model, try the build flow, and tell me where it breaks.

Maybe the mental model makes sense.
Maybe it needs better examples.
Maybe the source integrations need to grow.
Maybe some parts are still confusing.

That is exactly the kind of feedback I want.

Open source keeps the conversation honest.

It also lets developers use the core idea without waiting for a hosted platform.

That felt important to me.

Try it

The quickest way to start is with the scaffold:

pnpm dlx create-statikapi my-api
cd my-api
pnpm dev

You can also use:

yarn dlx create-statikapi my-api

or:

npx create-statikapi my-api

The examples in the repo show the current shape:

example/basic shows a simple static endpoint
example/dynamic shows dynamic and catch-all routes
example/showcase includes TypeScript and build-time remote fetches

The basic idea is still the same:

Create API-like route files.

Build them.

Get static JSON output.

What I want feedback on

I would genuinely love feedback on the idea.

Especially around questions like:

Does this mental model make sense?
What kind of APIs would you generate statically?
What source integrations would make this more useful?
Where would this fit in your real projects?
What would stop you from using something like this?

If the idea feels useful, I would really appreciate a star, comment, issue, or even criticism.

GitHub: https://github.com/zonayedpca/statikapi

Closing

I am not claiming every API should become static.

I am saying some APIs probably should not need a runtime at all.

That is the space I am exploring with StatikAPI.

And instead of keeping the idea in my head forever, I wanted to put it out in the open and see what other developers think.

Introducing Electron Gatsby Boilerplate

Zonayed Ahmed — Wed, 13 May 2020 21:51:05 +0000

I was looking for a Gatsby Electron Boilerplate, but I didn't find any. Then I have decided to make one myself. This is what I have come up with till now. It is a simple, minimal Electron Gatsby Boilerplate. Create a new BrowserWindow easily and speed up your development experience. It also included Automatic Linting, Redux, TravisCI Configuration, and GitHub Release.

GitHub Repo: https://github.com/zonayedpca/electron-gatsby-boilerplate
Release Demo: https://github.com/zonayedpca/electron-gatsby-boilerplate/releases

Any kind of Recommendation, issue, PR is welcome.

Also, don't forget to give a star if you think it's useful. Thank You!