DEV Community

Pascal Programming

Bek Brace — Sat, 01 Aug 2026 08:04:47 +0000

One small confession before we begin.

The first programming language I ever used was not Pascal. It was the built-in BASIC on the Atari 800XL home computer. At the time, in Egypt, that was what was available to many of us—mostly home computers imported from Saudi Arabia and Kuwait, including the famous SAKHR Arabic computers.

Surprisingly, I wasn't introduced to Pascal until I was 39 years old.

Perhaps it was my own ignorance, or perhaps my attention had been captured by newer systems programming languages like Rust, Zig, and Odin. Whatever the reason, I now feel I discovered Pascal far later than I should have.

The more I write in Pascal, the more I appreciate its elegance. Its syntax is remarkably clean, easy to read, and easy to learn. In many ways, it almost reads like plain English—you feel as though you're simply having a conversation with the computer. That clarity is one of the reasons Pascal has remained a beloved teaching language for decades.

After spending some time reading about the language and its history, I found that the modern Pascal ecosystem can be summarized as follows:

1. Free Pascal Compiler (FPC)

This is the compiler I currently use. It is free, open source, and actively maintained. FPC supports Windows, Linux, macOS, BSD, ARM, and many other platforms, making it one of the most versatile Pascal compilers available today.

2. Lazarus

Lazarus is the most popular free IDE for Free Pascal.

Think of it as the Pascal equivalent of Visual Studio for C# or Code::Blocks for C (although I'm not sure how many people still use Code::Blocks in 2026!). It provides a modern editor, debugger, project manager, visual form designer, and everything you need to build Pascal applications.

3. Delphi (Object Pascal)

Delphi is the commercial branch of Pascal and the direct successor to the legendary Turbo Pascal. It includes both an IDE and a compiler and is still widely used for developing professional desktop and business applications.

4. Turbo Pascal

The classic Borland compiler that introduced an entire generation to programming.

If you programmed during the DOS era, chances are you've seen its iconic blue IDE. It was famous for its incredibly fast compiler and became one of the most influential development environments of the 1980s and 1990s.

                    Pascal
                       │
        ┌──────────────┴──────────────┐
        │                             │
 Classic Pascal                 Object Pascal
        │                             │
        │                        Delphi
        │                           │
        │                           ├── VCL
        │                           └── FireMonkey
        │
        └─────────────┐
                      │
             Free Pascal (FPC)
                      │
          ┌───────────┴───────────┐
          │                       │
      Lazarus IDE          Castle Game Engine

If you've ever been curious about Pascal, I've put together a short introductory video covering its history, the different Pascal ecosystems, and how to get started with Free Pascal and Lazarus.

Thank you for taking the time to read this and watch the video.

I'd also love to hear about your own experience. Did you learn Pascal at school or university? Was it your first programming language, or did you discover it later in your career? Share your memories in the comments!

Offline Table Builder: Build Tables Without an Internet Connection

Olayiwola Akinnagbe — Sat, 01 Aug 2026 08:00:00 +0000

Most web tools stop working the moment you lose your internet
connection. For a table builder used on a train, in a conference
room with spotty wifi, or on a flight, this is a real problem.

Progressive Web Apps solve this through service workers, a background
script that caches the application assets and intercepts network
requests. When you open a PWA without internet access, the service
worker serves the cached version of the app. The tool works exactly
as it does online.

Tablesmit is a PWA. The first time you visit tablesmit.com, the
service worker caches the application. After that, you can open it
without internet access and every feature works: editing, formatting,
all export formats.

The exports (PDF, Excel, LaTeX, CSV, PNG, JPEG) all run client-side
using jsPDF, ExcelJS, and html2canvas. None of them require a server
call. The export file is generated in your browser and downloaded to
your device.

To install Tablesmit as a PWA: on Chrome or Edge, look for the install
icon in the address bar. On Safari on iOS, use Share → Add to Home Screen.
The installed app opens like a native application and works offline
without opening a browser first.

The offline capability also means your table data never leaves your
device. There is no server, no database, no sync. The table you build
exists only in your browser session until you export it.

Free, no account, MIT licensed. tablesmit.com

This post originally appeared on the Tablesmit Blog at tablesmit.com/blog/offline-table-builder. Tablesmit is a free, open source table builder. Export to PDF, Excel, LaTeX, CSV, PNG. No account required. Try it at tablesmit.com.

Fixing a Search Race Condition in npmx

Anil Loutombam — Sat, 01 Aug 2026 07:55:07 +0000

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

Project Overview

npmx is a modern browser for the npm registry. It provides package search, version timelines, dependency information, comparisons, and other tools for exploring npm packages.

Bug Fix or Performance Improvement

I worked on a search bug reported in issue #2617.

When the saved page size was 50 or higher and instant search was disabled, the first search could show no package results. The organization suggestion still appeared, and reloading the same search page made all the package results appear.

That made it clear that the packages existed and the request was working, but something was going wrong while the search page was being initialized.

Code

Pull request: npmx-dev/npmx.dev#3109

The fix waits for an initial search that is already in progress:

if (asyncData.status.value === 'pending') {
  await asyncData.refresh({ dedupe: 'defer' })
}

My Improvements

The page-size preference is stored locally. During the first navigation to the search page, the search could start with the default size of 25. The saved preference would then load and change the requested size to 50 while that search was still pending.

This triggered fetchMore before the initial response was ready. It could read the temporary empty response and store it in the search cache. The completed response arrived afterward, but the empty cached value took priority, so the page displayed no packages.

I updated fetchMore to wait for the pending search before reading its result. I used dedupe: 'defer' so it joins the request already in progress instead of cancelling it and starting another one.

I also added a regression test that changes the requested page size while the initial Algolia search is pending. The test verifies that the completed package results are preserved.

After the fix, the package results appear on the first search without requiring a reload.

I Was About to Spend Money on Ads. So I Made an AI Agent Test My Product for 29 Hours.

Kevin Kan — Sat, 01 Aug 2026 07:54:42 +0000

872 million tokens processed — 97.63% of them cached inputs. 5,222 tool calls. 88 issues closed. Zero critical bugs, and several high-severity ones, in a product I had been QA-ing the whole time I built it.

A note before we start. There's nothing exotic in this setup — no Hermes harness, no custom framework. Just Codex and a long prompt. I'm sure a properly configured Hermes run would measure all of this far more rigorously. I just don't think many people have gotten there yet, and I wanted to show what's already reachable without it.

This didn't start as an experiment. It started as nerves.

I was getting ready to run paid ads. Once you start buying traffic, every broken screen costs money — you're paying to deliver strangers to your worst bug. And I had a specific fear: my product runs in multiple languages, and I am not equally fluent in all of them. If something quietly breaks in one locale, I might not notice for weeks. The ads wouldn't stop running. They'd just keep working perfectly, delivering people to something broken.

So instead of clicking around for an afternoon and calling it good, I handed the whole thing to Codex and told it not to stop until it ran out of things to break.

It ran for just under 30 hours.

The instructions

The prompt mattered more than I expected, so here it is, cleaned up. Most of the specificity in it exists because vague instructions produce vague testing.

Objective I'm about to start paid advertising. Before I pay to send strangers to this product, find what they'll hit.

Ground rules

Depth — the happy path is the starting line, not the finish: repeat and double-click and fire concurrent requests; interrupt mid-flow with a refresh, a navigation, a sign-out, a return; switch language mid-session and check that state survives; kill a step deliberately and verify both recovery and usage accounting; mobile, tablet, desktop; keyboard-only, focus, labels, contrast; and check privacy boundaries — can any account see anything it shouldn't?

For every issue Record: what a user would see, exact reproduction steps, root cause in the code, severity (Critical / High / Medium / Low), the fix, the regression test that now covers it, verification after deploy.

Process: Read docs/ first. Fix as you go in small, traceable commits. Deploy to main and re-verify in the live environment. A fix isn't done until it has been checked in production.

Output: A separate report per language, plus one consolidated severity-ranked summary.

Rule 4 and rule 5 are there because of what happened during the run. I'll get to that.

The loop

Deliberately boring:

Observe, Reproduce, Investigate, Fix, Test, Verify, Repeat.

The rule that made the difference was refusing to trust a single pass. A screen working once proves almost nothing. So every flow got revisited after refreshes, sign-outs, restarts, language switches, repeated requests, deliberate failures, and finally, after deployment.

The numbers

Metric	Result
Total elapsed time	29h 45m 49s
Recorded agent work time	24h 57m 59s
Major work turns	9
Total tool calls	5,222
Browser-control calls	2,408
Shell / Git / test / deploy calls	2,570
Monitoring and wait calls	134
Images inspected	50
PDF analyses	8
Issues recorded and addressed	88
Total commits	126
Targeted fix commits	111
Automated web checks passed	829
Automated hook checks passed	95

Type checking, linting, builds, and the final test suites all passed before I called it finished. And "finished" didn't mean the last commit, it meant deployed, re-checked in the live environment, and synced back to main.

Yes, it processed 872 million tokens

Here's the headline number, and here's the asterisk, right next to it where it belongs.

Token type	Count
Total processed tokens	872,027,184
Input tokens	870,333,094
Cached input tokens	849,674,240
Non-cached input tokens	20,658,854
Output tokens	1,694,090
Reasoning tokens	512,615
Non-cached input + output	22,352,944

872 million is a genuinely fun number to say out loud. It is also 97.63% cached input.

That's what a long-running session looks like from the inside: the same codebase, the same reports, the same accumulated conversation, re-processed on every turn. The cumulative counter faithfully counts all of it. It does not mean 872 million new tokens were introduced or billed as fresh usage.

If you want the number that describes actual new context and generated work, it's roughly 22.35 million, non-cached input plus output.

I'm publishing both, because a large AI usage figure only means something when the caching structure sits beside it. Total volume without the ratio isn't measurement, it's marketing.

Where I had to step in

Two days is long enough that I checked in on it periodically, not reviewing every commit, just watching screens go by and asking myself whether what I was seeing looked right.

The first catch was mine. In every language but one, a particular record displayed correctly. In that one language, it didn't. The agent had looked at that screen, registered it as acceptable, and moved on. I flagged it manually. Once pointed at directly, it was diagnosed and fixed quickly. The fix was never the hard part. Noticing was.

That's the exact failure mode you should expect from an agent working alone: it is very good at "does this throw an error," and much weaker at "does this look wrong compared to the eleven other times I saw something similar." Rule 4 in the prompt above exists because of this.

The second catch came after the run was already declared complete. Going back through the results myself, I found a PostHog event that wasn't firing correctly, the one that records a completed payment.

Think about what that means in context. I was doing all of this to prepare for an ad campaign. The number I would have used to judge whether the ads were working was broken. No screen looked wrong. No test failed. Nothing threw. It would simply have been quietly incorrect forever, on the single metric that mattered most for the thing I was about to spend money on.

That's rule 5. Verify past the screen. A green checkmark that didn't emit its event is not a pass.

What actually changed

88 tracked issues, 111 targeted fix commits. The mismatch is the interesting part: one observed problem usually needed several independent changes. A single inconsistency could touch persisted data, restored UI state, translated output, failure recovery, and test coverage. Rather than folding that into a few fat commits, everything was split into small, traceable units.

The fixes clustered into a few themes:

More reliable state restoration when returning to a workflow
More consistent handling of repeated or concurrent actions
Better recovery when an operation dies partway through
Stronger file and document boundary handling
Fewer layout breaks across languages and screen sizes
Clearer protection against unintended internal-data exposure
New automated tests on paths that previously had none

The volume of changed code isn't the point. The point is that every fix traces back to an observed behavior, a reproducible case, and a verification step.

The part that actually bothered me

No critical bugs. Good.

But there were high-severity ones. Plural. In a product where I had been running QA continuously while building it.

That's the finding I keep coming back to, and it's more useful than any of the numbers above. I hadn't been careless. I'd been checking as I went. And a hard 30-hour pass still surfaced multiple high-severity problems that ordinary development QA had walked straight past.

Then the stress campaign itself finished, and I found two more things by looking with my own eyes.

There's a popular idea right now that AI just handles this, that you point a good model at a codebase and quality is a solved problem. This run is strong evidence for how far agents have come, and it's equally strong evidence against that idea. Development-time QA missed things. A 29-hour adversarial campaign caught most of them and still missed the ones a human caught by paying attention. So the honest conclusion isn't "now it's clean." The honest conclusion is:

There are almost certainly still latent bugs in there.

I'll run this again. Right now I believe there is nothing high-severity left. Believe, not know. That distinction is the entire point of writing this up.

What I'd tell someone doing this

Continuity is the capability, not intelligence. A one-off prompt fixes a visible bug. An agent that stays with the product discovers how that bug behaves once you add retries, localization, generated files, and a user who wanders back three steps later.

Browser access and code access are far stronger together. Browser automation tells you something failed. Source access tells you what might fail. Only both together let it see the symptom, trace the implementation, apply the fix, and walk the same journey again to confirm.

A fix without a regression test isn't finished. The screen looking better is not evidence. Where practical, every corrected behavior got a test so a future change can't quietly undo it.

Forbid "probably fine" explicitly. Agents skip small anomalies for the same reason tired humans do, nothing was on fire. Write the rule into the prompt: an inconsistency across languages is a finding, not a mood.

Verify beyond the UI, especially analytics. Events, emails, generated files, and stored state are where silent failures live. These are exactly the bugs that survive a successful test run.

Stay in the loop. The agent extended my reach enormously. It did not take over ownership. Both times something important slipped through, the thing that caught it was a person looking at the screen and thinking hmm, that's odd.

The question worth changing

The most useful outcome here wasn't any single fix. It was watching an agent hold an entire product-stabilization cycle, navigating, inspecting evidence, editing code, running tests, managing changes, waiting on external processes, and coming back to verify, for 30 straight hours.

Which means we've been asking coding agents a slightly small question. Not only:

"Can you build this feature?"

But also:

"Can you keep testing this product, investigate what breaks, fix the root causes, prove the fixes hold, and keep going until the validation criteria are met?"

That's a completely different job description. And right now it may be the most practical one we have, as long as somebody is still watching.

Originally published on Kanapp Notes.

Complex Requirements Are Not the Biggest Problem Anymore: Why Workflow Quality Matters More in the AI Era

Awaliyatul Hikmah — Sat, 01 Aug 2026 07:50:01 +0000

How we used AI to make CI stricter, more observable, and easier to improve across repositories.

Having worked across both implementation and delivery, I’ve learned that complex requirements are not necessarily the biggest problem in the current AI era.

AI can help us break down requirements, explore unfamiliar repositories, and generate implementation ideas. That makes the implementation step much easier.

But implementation is only one part of delivery. The feature still has to move through a real engineering system.

It has to fit the repositories, CI rules, review process, and deployment path that deliver it.

As implementation gets faster, the surrounding engineering system becomes more important. The real challenge is making sure every change is tested, reviewed against the requirements, and safe to merge.

Beyond the Fear of Replacement

There is a lot of fear around AI replacing developers.

Some of that concern is reasonable. Entry-level opportunities may become more limited when routine implementation tasks can be generated, tested, and reviewed with AI assistance.

That is an important challenge, especially for people who are trying to get their first opportunity in software development.

But I do not see this as the end of the developer role.

I see it as one of the most exciting periods to work in software.

The value is shifting.

Writing routine code is becoming less differentiating. Understanding a problem, asking the right questions, validating behavior, making trade-offs, and taking responsibility for the result are becoming more important.

AI can produce an implementation, but it does not automatically understand the business context, the hidden constraint, the operational risk, or whether the solution is appropriate for the team.

That is why workflow quality matters.

The developers who benefit most are not necessarily the ones who ask AI to generate the most code. They are the ones who can use AI inside a disciplined process: define the requirement, inspect the evidence, test the result, review the risk, and improve the system around it.

For junior developers, the path may change, but it does not disappear. Fundamentals, debugging, communication, product understanding, and the ability to work effectively with AI will matter even more.

That shift in perspective changed how we approached our CI. We did not start by asking how to make it run faster. We asked how to make it catch more of the right problems.

The Real Work Was Strengthening the CI Workflow

Recently, we worked on a GitLab CI workflow with several responsibilities:

Move linked issues to Status::In Review when a merge request is created.
Move issues to Status::Done after the merge.
Run an AI review for the entire merge request.
Block the pipeline when the AI review confirms a critical or high-severity finding.
Leave a comment when the merge request does not contain a closing reference.

The important part was not simply adding more CI jobs.

We used AI to inspect the workflow itself and ask better questions:

Does Status::In Review prove that the merge request is actually connected to a ticket?
Does Status::Done run only after a real merge to the default branch?
Can an AI finding block a merge without concrete evidence?
What happens when a merge request is missing a closing reference?
Which checks are generic policy, and which checks belong to one repository?

These questions changed the CI from a collection of commands into a quality control system.

The goal was not to make CI more complicated. It was to make each decision more explicit: what is checked automatically, what evidence is required, and what should block the merge.

How AI Is Actually Used in the Pipeline

The AI review is not a separate tool that developers have to run manually. It is a GitLab CI job that runs when a merge request targets the default branch.

The setup has four simple parts:

A pinned AI CLI is installed in the CI job.
A small repository script collects the merge request context.
The AI returns a structured JSON report.
A separate job evaluates that report and decides whether the pipeline passes.

The job uses a pinned version of the AI CLI instead of installing whatever happens to be latest:

ai_review:
  image: node:22-bookworm-slim
  before_script:
    - npm install --global @openai/codex@<pinned-version>
  script:
    - python scripts/ai_review.py review

In this case, the AI is accessed through the OpenAI Codex CLI. The exact CLI can vary, but the important parts are that the version is explicit and the job runs in an isolated CI environment.

The repository script does not send the entire repository blindly to the model. It collects only the context needed for the review:

the merge request description;
linked closing issues and their requirements;
the changed files and diff;
relevant file content around the changes;
the current commit SHA and target branch.

The prompt also defines what the AI is allowed to conclude. For example, a requirement is marked as Covered, Partial, Missing, or Not verifiable. A finding must include its category, severity, affected path, evidence, impact, and recommendation.

The response is validated against a JSON schema before it is used. The report is then saved as a CI artifact and posted as a merge request comment. This makes the reasoning visible and gives the next job a stable input.

The credentials are separated by responsibility:

an AI access token allows the review job to call the AI tool;
a GitLab automation token allows the workflow to read merge request data and update comments or labels.

Both are managed as masked group-level CI variables. The review job uses the AI token. The gate job does not need to call the AI, so it consumes the report artifact and removes the AI token from its environment.

This separation is useful for two reasons. It limits where sensitive credentials are exposed, and it prevents the final gate from making another AI request whose result could differ from the report that was reviewed.

In practice, the flow looks like this:

Merge request
    -> collect GitLab context
    -> AI review with structured output
    -> report.json artifact and comment
    -> deterministic gate
    -> pass or block the pipeline

AI is therefore used for analysis and explanation. GitLab CI remains responsible for validating the output, checking the commit, updating the merge request, and enforcing the final policy.

Package the Improved Workflow, Not the Repository

The shared component was a useful result, but it was not the main improvement. The main improvement was making the CI policy explicit and enforceable. Once that was clear, we could package the reusable parts.

After improving the workflow, the next question was simple:

Do we really need to set up the same workflow manually in every repository?

The answer was still no.

Instead of copying the improved .gitlab-ci.yml logic into every repository, we created a shared GitLab CI component.

The consumer repository only needs to include the shared template:

include:
  - project: your-group/ci-components
    ref: v0.1.0
    file: /templates/issue-ai-review.yml

The shared component provides:

issue_status_in_review
issue_status_done
ai_review
ai_review_gate

The repository still owns its own build, lint, unit test, E2E, and deployment jobs.

This separation is important.

A Go repository should not be forced to use a Python repository structure. A frontend repository should not inherit a backend test command.

But both repositories may still need the same merge request policy.

The reusable part is the quality policy, not every command in the pipeline.

AI Review Needs a Deterministic Boundary

AI review is useful, but an AI response should not directly decide whether a merge request can be merged.

The AI reviewer produces a structured report. It evaluates ticket coverage, correctness, regression risk, security, performance, maintainability, and other categories.

Critical and High findings are then independently verified.

The final gate checks deterministic conditions:

Is the report for the current commit?
Was the finding independently confirmed?
Is the severity still blocking?
Was a human override added after the report was generated?

This gives us a better boundary.

AI is useful for reasoning over a large merge request.

The pipeline is responsible for enforcing the policy.

That distinction matters because AI output is probabilistic, while a merge gate should be predictable.

Making the Workflow Safe to Reuse

The quality of the workflow does not come from the AI step alone. We also need to make the automation predictable and safe to reuse.

Missing closing references become visible

If a merge request does not contain a reference such as Closes #123, the pipeline automatically leaves a comment explaining what is missing.

The job also fails, so the problem is visible before the merge. After the description is updated, the pipeline can be retried.

Pin the shared component

Each repository uses a specific component version, such as v0.1.0, instead of silently following the latest changes.

This means an update to the shared CI does not unexpectedly change every repository. A repository can update the version when the change has been reviewed.

Use a dedicated bot for automation

The workflow needs credentials to update issue labels and comments. Those credentials are stored at the group level and belong to a dedicated CI bot instead of a developer's personal account.

This keeps ownership with the team and makes the automation easier to maintain when people or responsibilities change.

Keep repository-specific checks local

The shared component handles the common merge request policy. Each repository still defines its own build, lint, unit test, E2E, and deployment jobs.

Labels can also be configured per repository. A Go project and a TypeScript project do not need to use the same commands just because they share the same review policy.

The result is a common quality bar without pretending that every repository has the same structure.

What Changes in Engineering Leadership?

AI changes the bottleneck.

Before, a large part of the work was translating requirements into code and manually checking whether the CI workflow captured the intended policy.

Now, AI can reduce much of that implementation friction.

The engineering leadership role becomes more focused on:

defining reusable boundaries;
deciding which checks must remain deterministic;
turning repeated policy into automation;
making AI output verifiable;
preserving flexibility between repositories; and
ensuring that speed does not remove evidence from the process.

The work is still complex.

But the complexity can be organized into smaller, reusable systems.

Final Takeaways

Complex requirements still need careful thinking.

AI does not remove the need for architecture, testing, or review.

But it changes what is practical.

A review process that depended on manual inspection can become an automated, evidence-based gate.

Once that quality policy is clear, the repeated CI logic can become a versioned shared component.

The biggest improvement is not just writing code faster.

It is creating a system where complex work becomes easier to coordinate, verify, and reuse.

That is where AI creates the most leverage for engineering teams.

Day 171 of Learning MERN Stack

Ali Hamza — Sat, 01 Aug 2026 07:49:22 +0000

Hello Dev Community! 👋

It is officially Day 171 of my full-stack web development journey, and I am thrilled to announce that QuickChat (MERN Stack Real-Time Chat App) is officially complete! 🎉🚀

Today, I finalized the last key security layer: JWT Authentication & Route Protection Middleware.

🛠️ Technical Breakdown: JWT Route Security

As captured in my implementation snapshots (auth.js & utils.js):

1. Token Signature Utility (`utils.js`)

Configured a centralized token generator helper signing payload userId parameters using environment secrets:


javascript
  const generateToken = (userId) => {
    return jwt.sign({ userId }, process.env.JWT_SECRET);
  };

Everything Is Reversed

Sinisa Kusic — Sat, 01 Aug 2026 07:48:09 +0000

What happens to a medicated ADHD brain when AI removes the last thing that used to slow it down.

I have ADHD, and I am medicated for it. I take it first thing. It lands about thirty minutes later, roughly as I finish the first coffee. Then I sit down to write software with an agent, and the day stops keeping time.

I look up thinking an hour and a half has gone, two at the outside. Six hours have gone. Later I step out for a cigarette, convinced I have been away too long, that it has been the better part of an hour. It has been fifteen minutes.

Both directions, most days. The work compresses and the breaks dilate. Nothing in me reports the difference, so I only find out by looking at a clock, and by then whichever it was has already happened.

The clock has run like that for years, medicated or not. That part is not about AI and I am not going to pretend it is. What AI changed is what fits inside those six hours.

Before the medication it arrived in bursts. A few good hours, occasionally a few good days, and long stretches in between where I could see the task perfectly clearly and could not begin it. Task paralysis is a mild name for what that is like. The bursts were real and I could not schedule them.

That part is gone. What replaced it does not switch off, and one task turns out not to be enough to hold it. There are two laptops on my desk. Some days both of them are working.

The appetite was already there

My brain likes information. Not needs, likes. Give it a thread and it will pull, and pulling feels like progress the entire time it is happening. The only thing that ever limited that was effort. Finding things was slow, so the appetite ran into a wall several times an hour, and the wall was doing something useful even though it felt like an obstacle.

The wall is gone. I can point AI at a repository, a ticket history, a chat archive, a document nobody has opened in two years, and have it back in seconds, summarised, in whatever shape I asked for. Gathering costs nothing now.

This is fuel on a fire that was already lit. The thing my brain most wants to do all day is the thing that just became free and unlimited.

Cheap to gather, expensive to know

Here is the reversal that matters more than the clock.

Gathering information is cheap. Working out which of it is relevant is not. Working out which of it is still true is not. Those decisions are mine, every one of them, and there are now vastly more of them per day because there is vastly more in front of me.

The AI will hand me a summary of a decision made three years ago with exactly the same confidence it hands me something from Tuesday. It has no view on which one the team still believes. I have to hold both, judge both, and pick. Then do it again, on the next thing, having had no gap in between.

That is the cost, and it is the part that does not get cheaper. Everything upstream of it collapsed to nothing, which means the whole day is now made of the expensive part.

Nobody calls out the AI

The thing that keeps this from being a productivity story is that ownership never moved.

Whatever ships with my name on it is mine. If the call was wrong, I am the one it comes back to. Nobody in a review has ever asked the model to explain itself. So the judgment cannot be delegated, cannot be batched, and cannot be skipped, and it sits on top of a brain that has already spent six hours in a state it could not measure.

I do not have a tidy answer to this. I know when it has gone badly, because it is seven in the evening and I would have told you it was three. I know the clock is the only instrument I have that tells the truth. And I know the part that costs me is not the work the tools took over. It is all the work they left behind, which turns out to have been the whole job.

The real cost of Instagram data in 2026 (measured, not estimated)

Sieve Seo — Sat, 01 Aug 2026 07:45:16 +0000

I spent the last week building a small "who unfollowed me" tool, which means I needed one boring thing: the follower list of an Instagram account. Here is everything I measured while figuring out how to get it in 2026 — what's dead, what's free, and what the paid options actually cost.

The free paths are mostly dead

Follower lists require a logged-in session. Period. I tried three separate unauthenticated paths (web API, GraphQL, mobile endpoints) and every one returns 401 for list data. No header combination fixes it.

Follower counts are still public — web_profile_info with the x-ig-app-id header returns the count, privacy flag, and following count in one response. But it's aggressively rate-limited per IP: in my tests, roughly 20 requests inside a 30–60 minute sliding window trips a 401 block that recovers after ~29 minutes. Spacing requests out doesn't help; it's a sliding window, not a fixed quota.

Don't bother from cloud servers. The same endpoint that worked from my home IP returned 429 with a 0-byte body in 16ms on the very first request from a cloud IP (I tested from a Vercel build container). That's not my usage history — that's the entire IP range being pre-banned. Public cloud IPs inherit the abuse history of every tenant before you, so you cannot have a "clean" cloud IP.

And no, the user's own browser can't do it for you. Even if your user is logged into Instagram, your web app's origin can't read Instagram responses — CORS blocks it, and no-cors mode gives you an opaque 0-byte response. This is a browser guarantee, not something you can engineer around.

The one genuinely free path: the official data export

Instagram's "Download your information" export gives every user their own follower/following lists as JSON or HTML — and it works for private accounts too. If your product can tolerate a "request export, come back later" flow, this costs exactly $0.

Parsing it has landmines, though:

followers_1.json and following.json have different schemas — followers keep the handle in string_list_data[0].value, but following keeps it in title, and the value field simply doesn't exist there.
Non-ASCII display names arrive mojibake'd (UTF-8 bytes decoded as latin-1: 이름 becomes ì´ë¦). Handles are ASCII-safe, but you must repair names before showing them.
Exports expire in 4 days, and a "full" export can be 500MB+ because it includes DMs — read the ZIP's central directory and slice out just the two files you need instead of unpacking it.

What hosted APIs actually cost

For the "type a handle, get results now" flow, I ended up on HikerAPI after comparing alternatives. Numbers from my real usage, not the pricing page:

A full scan of a ~1,060-follower account took 43 requests, about 3 minutes (cursor-chained pagination, so you can only parallelize followers vs following, not pages).
Page sizes differ per endpoint family and it matters for cost: the g2 follower endpoint returns 25 users per billed request, while g1 returns 46 per billed request — same data, nearly half the cost. The docs don't advertise this; I found it by reading their public OpenAPI spec and testing.
Billing is verifiable: /sys/balance shows a request counter, and I confirmed call-by-call that list pages bill exactly 1 unit — and that a deprecated endpoint returning 410 billed nothing.
Accuracy: I cross-checked one page of API results against data collected directly from Instagram's web interface — 89/90 matched, and the one mismatch was a follower gained between snapshots.
Cost at the $100 prepaid tier: $0.001/request, so ~$0.04 per 1,000 followers scanned with the 46-per-page endpoint.

Two honest gotchas: card top-ups carry a 15% fee deducted from your balance (only crypto avoids it), and until you've deposited $100 total you pay ~20x per request, which makes small-scale testing feel more expensive than the steady state.

For comparison, the cheapest Instagram scraper actors I tested on Apify worked out to 9–20x more per follower than the numbers above — partly because one actor advertised "50 users per $0.009 batch" but returned 25 users while billing the full batch. Always measure billed units, not advertised prices. Enterprise proxies (Bright Data class) were 30x+ for this use case.

A curl you can verify all of this with

# profile gate: 1 request buys you count + privacy flag
curl -H "x-access-key: $KEY" \
  "https://api.hikerapi.com/v1/user/by/username?username=instagram"

# follower page: 1 request, ~46 users, cursor in response
curl -H "x-access-key: $KEY" \
  "https://api.hikerapi.com/g1/user/followers?user_id=25025320"

(One quirk: their Cloudflare config rejects Python's urllib user-agent with a 403 — curl and normal HTTP clients are fine.)

Takeaways

Decide early whether your product needs lists or just counts — counts are free-ish from a residential IP, lists are never free without the user's own export.
If you go hosted, read the OpenAPI spec and measure billed units yourself — endpoint families differ by ~2x in cost for identical data, and advertised prices routinely don't survive contact with real usage.
Keep the official export flow as a fallback: it's the only path that covers private accounts, and it costs nothing.

What else are people using for this in 2026? Especially curious if anyone has a cleaner answer for private-account analytics than the export flow.

Two of my projects were about to jump a grade. Nobody had fixed anything.

FromZeroToShip — Sat, 01 Aug 2026 07:41:00 +0000

I have a scanner that grades my own projects. It reads the code, applies a list of rules, subtracts points per finding, and hands each project a letter grade. It exists because I build with AI and needed something that wasn't me deciding whether my work was fine.

Someone in a thread here pointed at a flaw in it that I couldn't argue with.

His point: my rules overlap. If two rules fire on the same underlying defect, the project is charged twice for one mistake. And — this is the part that made me sit up — that error can only land on projects that have the defect. A clean project is never double-charged, because there's nothing to charge. So the penalty is regressive: it pushes the worst projects further down and leaves the good ones untouched, which means my grade distribution is stretched at the bottom by a bug rather than by reality.

That's a real argument. My instinct was to fix it that evening.

What I did instead

I've been burned enough times this month by fixes that felt obviously right. So before changing the scoring, I wrote something to measure whether the thing he described is actually happening in my data.

The measurement is simple: for every finding, record which rule fired and where. Then count how often two different rules fire at the same file and line.

// count co-occurrence of different rule keys at the same file:line
const seen = new Map();                       // "file:line" -> Set(ruleKey)
for (const f of findings) {
  const at = `${f.file}:${f.line}`;
  if (!seen.has(at)) seen.set(at, new Set());
  seen.get(at).add(f.key);
}

const pairs = new Map();
for (const keys of seen.values()) {
  const ks = [...keys].sort();
  for (let i = 0; i < ks.length; i++)
    for (let j = i + 1; j < ks.length; j++) {
      const p = `${ks[i]}||${ks[j]}`;
      pairs.set(p, (pairs.get(p) ?? 0) + 1);
    }
}

Then: recompute every project's score with duplicates collapsed, and compare.

What came back

72 projects. Ten rule pairs that ever co-occur. Here are the top four:

Rule pair (co-firing at the same line)	Times
missing social preview + missing standard footer	32
`SELECT *` + no performance diagnostics	22
suspected N+1 query + no performance diagnostics	16
suspected N+1 query + `SELECT *`	14

Look at the top one. "No social preview tag" and "no standard footer" are not one defect seen twice. They're two genuinely separate omissions that happen to live in the same file, because that file is the page template. Collapsing them wouldn't remove a double charge — it would stop charging for a real second problem.

The same is true further down. SELECT * and missing diagnostics co-occur because both are symptoms of a page written quickly, not because one implies the other.

Then I checked his actual prediction — that the correction should lift the worst projects most:

Original grade band	Projects	Avg. points gained by deduplicating
F (0–59)	2	+0.50
D (60–69)	1	+1.00
C (70–79)	4	+1.50
B (80–89)	11	+0.82
A (90–100)	54	+0.39

The uplift peaks in the middle, not at the bottom. If the regressive error he described were the dominant effect in my data, that F row should be the largest number in the table. It's the second smallest.

Two projects would have moved from B to A. Not because they improved. Because I applied a correction for a problem I hadn't confirmed I had.

So I didn't ship it.

The part I have to admit

Here's what stops this from being a story about being clever.

Look at the sample sizes. F is two projects. D is one. The bottom of that table, where the entire argument lives, is three data points. "The uplift peaks at C" is a sentence I can write and cannot really defend.

So the honest conclusion isn't "he was wrong." It's narrower and less satisfying: I don't have enough bad projects to know whether he's right, and shipping the fix would have changed real grades based on a theory I couldn't test. The measurement didn't prove him wrong. It proved I was about to act on faith and call it engineering.

If my next twenty projects include eight bad ones, that F row becomes meaningful and I'll rerun it. The script is committed, the baseline is stored, and it compares against that baseline on every run — so the day the answer changes, something tells me instead of waiting for me to wonder.

What I actually took from it

Three things, and only one of them is about scoring.

A good argument is not a measurement. His reasoning was sound and might still be correct. Sound reasoning about your data is a hypothesis, and it costs about an hour to find out which one you have.

Fixes have a direction, and you should predict it before you look. The reason this was checkable at all is that his claim made a prediction: the correction should help the worst projects most. That gave me something to compare against. Advice that doesn't predict anything can only be accepted or ignored — never tested.

Report what the measurement can't say. My first draft of this post ended at the table, with the uplift peaking at C, sounding conclusive. Adding "n=2" to that row changed my own conclusion while I was writing it.

So, genuinely: thank you for the flaw. It's on the list, with the measurement attached and a condition that will tell me when it starts to matter. That's a better outcome than shipping it would have been — and it took longer to write this post than to run the test.

This is part of Stolen from the Feed — what a non-developer carries home from dev.to and actually builds. Sister series to From Zero to Ship.

What UK Bootstrapped SaaS Founders Actually Pay for Business Banking

Ben Clifford — Sat, 01 Aug 2026 07:39:38 +0000

"Free business banking" is one of the most misleading phrases in UK fintech marketing. Every major digital bank advertises a free tier — Starling, Tide, Mettle, Monzo, Revolut — but "free" depends entirely on how many transfers you make, whether you invoice, and whether you touch foreign currency. Here's what five common bootstrapped-founder scenarios actually cost, worked out line by line.

Scenario 1: Solo SaaS founder, 10 transfers a month, no invoicing

You're paying a couple of contractors and a hosting bill. Nothing fancy.

Starling: £0. Unlimited free UK transfers, no monthly fee.
Mettle: £0. Same story, plus FreeAgent (~£150/year value) thrown in.
Monzo Lite: £0.
Tide: 5 transfers free, then 5 × £0.20 = £1/month.
Revolut: £10/month minimum (Basic plan fee applies regardless of volume).

At this volume, Starling, Mettle, and Monzo Lite are functionally tied at zero cost. Revolut is the expensive outlier here because you're paying for multi-currency capability you're not using.

Scenario 2: Invoice-heavy consultancy, 50 transfers a month, client invoicing

You bill clients directly and chase payments monthly.

Tide: 5 free transfers, then 45 × £0.20 = £9/month, plus 3 free invoices monthly (extra invoices need the paid Smart plan at £12.49/month if you exceed that).
Starling: £0 for transfers, but invoicing is a £7/month add-on — so roughly £7/month.
Monzo Pro: £9/month flat, invoicing included.
Mettle: £0, invoicing included via bundled FreeAgent the cheapest option if you don't need multi-user access or international payments.

For a solo consultancy that only invoices UK clients, Mettle wins on pure cost. The moment you need a second user or an international client, that calculus changes fast.

Scenario 3: Cash-heavy small retailer/market trader, £2,000/month in cash deposits

Starling: 0.7% at the Post Office, minimum £3 — on £2,000 that's £14/month.
Tide: 0.5% at Post Office (min £2.50) or 3% at PayPoint Post Office route costs £10/month, PayPoint costs £60.
Mettle: up to £500/day free at the Post Office, so £2,000 spread across the month can land at £0 if you deposit in smaller batches but confirm current terms directly with Mettle, as cash deposit policy details vary.
Monzo Lite: £500/month free, so anything above that starts incurring charges.

Cash-handling businesses should model this scenario specifically it's the one place "free" digital banking quietly becomes the most expensive option on the list.

Scenario 4: Exporting SaaS, billing US and EU clients in USD/EUR

Revolut: £10/month, but you get 25+ currencies at interbank rates for the first £1,000 monthly, then 0.6% FX on weekdays (1% weekends). For a founder converting say £5,000/month, that's roughly £10 + (0.6% × £4,000) = £34/month.
Starling: EUR add-on only, limited multi-currency workable for EU-only, not for USD.
Others: no meaningful multi-currency support, meaning you'd be paying your card processor's FX markup on top of a domestic-only account, which is typically a worse rate than Revolut's interbank pricing.

If you're actually invoicing in foreign currency every month, Revolut's £10 fee is usually cheaper than eating a worse FX spread elsewhere.

Scenario 5: Growth-stage, want lending headroom

Only one account on this list offers overdrafts and business lending as a fully licensed bank: Starling. Monzo Business also offers overdrafts and loans subject to credit checks.
Tide, Mettle, and Revolut don't offer overdrafts at all. If you're planning to need short-term credit as you scale, that's not a fee comparison — it's a structural feature only some of these accounts have.

The actual lesson

None of these accounts is "cheap" or "expensive" in the abstract cost is a function of your transaction pattern, not the marketing page. Map your real monthly numbers (transfers, invoices, cash, foreign currency) against the scenario closest to yours before deciding, because the gap between the cheapest and most expensive option for your specific pattern can be £30-40 a month real money for a bootstrapped founder.

All fees and limits verified against provider websites as of mid-2026 banking fee structures change, so confirm current pricing before choosing an account.

Day 170 of Learning MERN Stack

Ali Hamza — Sat, 01 Aug 2026 07:34:21 +0000

Hello Dev Community! 👋

It is officially Day 170 of my full-stack engineering track! Today, I designed and implemented the backend message retrieval and chat history processing endpoints (getUserforSidebar & getMessages) for QuickChat using Node.js, Express, and MongoDB! ⚙️💬

Here is how I structured the database queries for chat retrieval and read receipts.

🛠️ Technical Breakdown: Message Fetching & Unseen Counters

As captured in my implementation snapshots (messageController.js):

1. Dynamic User Discovery & Parallel Unseen Counting

Filtered out the currently logged-in user using Mongoose $ne operator while stripping out password projections.
Used Promise.all alongside map iterations to asynchronously gather unread message counts per user card:


javascript
  const filteredUser = await user.find({ _id: { $ne: userId } }).select("-password");

  const promise = filteredUser.map(async (user) => {
    const messages = await message.find({ senderId: user._id, receiverId: userId, seen: false });
    if (messages.length > 0) {
      unseenMessages[user._id] = messages.length;
    }
  });
  await Promise.all(promise);

I Stopped My AI From Making Up AWS Answers With One Command

Steven Leung — Sat, 01 Aug 2026 07:34:07 +0000

The Problem

AWS announces changes continuously, any reader here would be familiar with that, and with the AWS News Blog.

Imagine you're a developer in July 2026 asked to work with Amazon S3 Files, which went generally available during April 2026.

Your AI assistant has a knowledge cutoff: a fixed date after which the model stops receiving new training data. Past that date, it's completely unaware of new product releases, feature launches, or documentation changes. Time is of the essence and you can't exactly pause until the next model ships.

AI assistants have made it easy to skip the manual grind of reading docs and researching things yourself, right up until the assistant's knowledge runs out of date. So what do you do when it doesn't know about the thing you need it to know about?

The Solution

Enter the AWS Knowledge Model Context Protocol (MCP) Server, an open-source tool from AWS Labs (AWS's official open source GitHub organisation) that connects AI models directly to authoritative, up-to-date AWS documentation.

It lets AI clients like Claude and Copilot pull real-time AWS information without waiting on a model update: current documentation, blog posts, What's New announcements, and Well-Architected guidance, all fetched live rather than recalled from training data.

What is MCP, for the uninitiated

The Model Context Protocol (MCP) is the standard AI tools use to talk to external tools and knowledge sources. AWS Knowledge is a remote MCP server, hosted by AWS, that puts AWS-specific material in front of the model in a format it can use.

You'd be forgiven for thinking this sounds like RAG (Retrieval-Augmented Generation). MCP enables RAG, but it isn't RAG itself, and RAG doesn't need MCP either. People were doing RAG long before MCP existed. MCP is the connector standard; RAG is the "look something up, then answer using what you found" pattern. MCP just happens to be a common way of wiring that pattern up.

What it gives the model

The server exposes a handful of tools the AI can call directly:

search_documentation: keyword search across all AWS documentation
read_documentation: fetches a specific documentation page, converted to markdown
recommend: suggests related documentation pages for a given URL
list_regions: lists all AWS regions and their identifiers
get_regional_availability: checks which regions support a given service, feature, SDK API, or CloudFormation resource
retrieve_skill: pulls down a domain-specific "agent skill", a packaged set of workflows and best practices for a more involved AWS task

That last one is worth a quick note: skills aren't new actions bolted onto the model, they're structured guidance the model reads and follows, the same way it would follow a detailed how-to doc, just retrieved on demand instead of baked into the prompt.

The important details

Client-server pattern: your AI tool is the client, AWS Knowledge is the server.
No AWS account required: it's public and unauthenticated.
Free to use: no cost, which makes everything easier.
Rate limited: it's a shared public service, so standard limits apply.

A quick note on privacy

Worth knowing what actually leaves your machine here: just your query text (e.g. "does Lambda support S3 Files yet") plus your IP address, going to a public AWS endpoint, the same exposure as searching the AWS docs site yourself. Nothing from your codebase, credentials, or AWS account goes with it, this server only answers questions, it doesn't read your project or touch your infrastructure. AWS states that telemetry from this server isn't used for model training, and since there's no authentication step, there's nothing tying a query back to your identity beyond standard request logs.

One rule of thumb regardless: fine for general AWS knowledge lookups, not the place to paste anything client-specific or commercially sensitive as part of a query.

See it in action

Once it's wired in, the difference shows up the moment you ask about anything recent. Try something like:

"Is Amazon S3 Files generally available yet, and which regions support it?"

Without AWS Knowledge connected, most models will either hedge ("I'm not aware of this service" or "as of my knowledge cutoff, this doesn't exist") or, worse, guess. With it connected, the assistant calls search_documentation, finds the GA announcement, and answers with the actual launch date and region list, sourced from the live docs rather than a guess.

That's the whole pitch in one prompt: the model goes and checks, instead of you doing it in a second tab.

How to install it

Claude Code

The claude mcp add command is specific to Claude Code's CLI, but AWS Knowledge itself is just a standard MCP server, so the same URL works in any MCP-compatible client. Only the registration step changes.

claude mcp add --transport http aws-knowledge https://knowledge-mcp.global.api.aws

If you want it available across a whole project, and checked into git so the rest of the team gets it too, add --scope project instead of leaving it at the personal default:

claude mcp add --scope project --transport http aws-knowledge https://knowledge-mcp.global.api.aws

Verify it worked:

claude mcp list
claude mcp get aws-knowledge

list shows connection status at a glance, get shows the full config and whether it's reachable right now.

VS Code, Visual Studio, JetBrains, and other Copilot IDEs

These all share a similar mcp.json config shape. The root key is servers, not mcpServers, that's the detail that trips people up if they're copying config from Claude or Cursor.

{
  "servers": {
    "aws-knowledge": {
      "type": "http",
      "url": "https://knowledge-mcp.global.api.aws"
    }
  }
}

Since AWS Knowledge is public and needs no authentication, that's the whole config, no tokens or headers required. Where you put it and how you open it differs by IDE:

VS Code: open the Command Palette and run MCP: Open User Configuration for something that applies everywhere, or create .vscode/mcp.json in a repo to scope it to that project and commit it for the team.

Verify it worked: run MCP: List Servers from the Command Palette, select aws-knowledge, and check its status. If it's erroring, choose "Show Output" to see the actual server log. In Copilot Chat (Agent mode), click the tools icon to see the live list of available MCP tools and confirm aws-knowledge is in it.

JetBrains (IntelliJ, WebStorm, PyCharm, etc.): click the GitHub Copilot icon, then Edit Settings, then Model Context Protocol, then Configure, which opens the same mcp.json.

Verify it worked: open Copilot Chat in Agent mode and click the tools icon at the bottom of the chat window. This opens the live tool list, confirm the AWS Knowledge tools show up there. If they don't appear right after saving, try reopening the chat window rather than assuming it's misconfigured, that's the most common false negative.

Visual Studio (2022, version 17.14.9+): create an .mcp.json file in your solution directory or %USERPROFILE%, using the same config shown above.

Verify it worked: after saving, Visual Studio shows a CodeLens prompt above the server entry, click it to connect. Then open Copilot Chat in Agent mode and use the tool picker to confirm aws-knowledge's tools are listed. Since this server needs no auth, it should connect straight away with no credential prompt.

Claude Desktop

This one works differently. Claude Desktop doesn't pick up remote HTTP servers from a config file at all, claude_desktop_config.json is for local servers only. Remote servers go through the UI:

Open Settings, then Connectors (Organization integrations, if you're on a Team or Enterprise plan).
Add a custom connector.
Paste in https://knowledge-mcp.global.api.aws as the server URL.
Confirm. The tools are available from your next chat.

No OAuth step here either, since the server doesn't require authentication.

Verify it worked: open the Connectors panel again and confirm aws-knowledge shows as connected with its tools listed, or just ask it something time-sensitive in a new chat and see whether it searches before answering.

If it won't connect

This is a public, high-traffic endpoint, so occasionally the issue is on AWS's end rather than your config. There's a known case where the server has briefly returned connection errors during initialisation across every client at once. If aws-knowledge looks correctly configured but won't connect, it's worth trying again a few minutes later before assuming your JSON is wrong.

Prefer to keep it local?

If you'd rather not depend on a remote, AWS-hosted server, for offline work or a stricter environment, AWS also publishes awslabs.aws-documentation-mcp-server, a locally run equivalent with overlapping search and read tools, installed via uvx instead of a URL. Same idea, runs on your machine instead of AWS's.

One thing worth watching

Every MCP server you connect adds to the list of tools your assistant has to consider on each turn. Adding AWS Knowledge is low-cost since it's just a handful of tools, but it's worth treating "add every MCP server that looks useful" as the wrong instinct. Add what you'll actually reach for, not everything available.

Final thoughts

This is low effort for high value, for only a bit of setup. One command, or one small JSON block, and you're done.

After trying it out, I'd call this a must for every developer working with AWS, and it left me wondering how I'd gone so long without it.

It cuts down the hallucinations by giving the model something current to check itself against, instead of relying purely on training data that's already going stale by the time you're reading this.

The bigger win for me, honestly, is staying in one place. No more jumping between the IDE (or terminal) and a browser tab full of AWS docs. That context switch between "coding" and "reading documentation" is a small tax we pay dozens of times a day, and it adds up. With this wired in, your AI assistant can just go check for itself, and you stay exactly where you were working.

What's the most recent AWS feature your AI assistant got completely wrong?

Drop it below, I want to see how bad the gap actually is.

If you'd like to connect or keep the conversation going, find me on LinkedIn.