The way I work as a software engineer has changed — and I didn’t exactly plan for it.

A few years ago, my day was mostly about implementations. Writing boilerplate, stitching things together, obsessing over the finer points of state management or input validation. But with the rise of AI tools — not just code assistants, but a growing ecosystem of intelligent helpers — something shifted. I found myself writing fewer lines of code, and instead spending more time designing, prototyping, and exploring ideas at a higher level.

Today, most of what I do is closer to rapid architecture and experimentation. I move fast — spin up MVPs, test proof of concepts, iterate, throw things away, rebuild. It’s liberating. But it introduced a new kind of bottleneck I wasn’t expecting:

Data.

Lots of DATA!

Almost everything I build needs mock data. And not just random fake names and emails — I’m talking about realistic, deeply structured, schema-specific data. Think of things like: a customer profile with conditional fields, nested address arrays, dates that follow logical patterns, optional properties, and so on. Every prototype, every API, every UI test — they all need something to work with.

At first, I didn’t think much of it. I’d just throw together a quick JSON object by hand. Then another. Then a third, slightly different. And before long, I was knee-deep in repetitive grunt work again — copying, tweaking, checking, re-checking. I was generating test data by hand more than I was writing actual features.

It hit me one night while building a prototype: I’d spent nearly an hour massaging mock data instead of solving the actual problem. And not for the first time. The frustration wasn’t even loud — just a quiet, dull hum that had been following me for years. I realized this wasn’t just a one-off pain point. This was a pattern.

I didn’t want to build another side project. I really didn’t. I had too many already, and I knew the cost of spinning up something new. But the idea wouldn’t leave me alone. What if I could define the structure of the data visually — not by writing JSON, but by shaping it intuitively — and have the machine generate the rest for me? Not magic. Not fantasy. Just something practical that worked.

So I started building it.

At first, it was rough. I stitched together a schema editor. Hooked in a basic validation system. Added a bit of natural language input for fun — something to help describe the data I wanted, not just its shape. And then I tested it. I built a schema for a customer record. Hit generate. And it worked.

I stared at the screen for a long moment. Not because it was perfect — it wasn’t — but because for once, I hadn’t had to fight the data. It felt... natural. Easy. Like something I would’ve used ten projects ago if it existed.

That little tool became what I now call:

“MockingJar”

It’s not a revolution. It’s not AI magic. It’s just a quiet little utility that solves a problem that kept getting in my way. A tool that knows how to treat structure seriously, that validates data properly, and that fills in the blanks in a way that respects what you’ve defined.

And more than anything, it’s a reminder that not all software needs to be loud or groundbreaking to matter. Sometimes, the most satisfying thing you can build is the one that makes your life 10% easier — every single day.

I didn’t mean to build it. But it wouldn’t stop bothering me until I did.

And I’m glad I did.

A Better Way to Fake Data (Without Faking It All Manually)

There’s something oddly painful about creating mock data.

It sounds simple, right? Just come up with a few fields, throw in some names and numbers, maybe a fake email or two — done. But if you've ever actually had to mock data for a real project, you know how quickly it spirals. One minute you're typing { "name": "John Doe" }, and the next you're deep in a jungle of nested arrays, conditional fields, date formats, min-max constraints, and a creeping sense that you’ve just become your own QA department.

That’s basically what led me to build MockingJar — a little tool that makes it easier to define structured JSON data and then generate mock content for it that actually makes sense.

The idea is simple: you describe the shape of the data you want — visually — and then MockingJar handles the rest. It builds out the schema, lets you customize every detail, and when you're ready, it fills it with realistic mock data.

But let me show you what that actually feels like.

You Don’t Write JSON — You Build It

Instead of starting with an empty text editor and a blinking cursor, you start with a blank canvas and a visual builder. You can add fields like "name", "age", or "email", choose their types (text, number, boolean, object, array, etc.), and define rules like whether a field is required, how many items an array should have, or what pattern a string needs to follow.

It’s kind of like building a form — except you’re designing the shape of the data your API or frontend might use later. The builder supports nesting, too, so you can go as deep as you want: objects inside arrays inside objects? No problem.

Describe What You Want, Then Hit Generate

Once your schema is ready, here’s where it gets fun: you can write a short, simple prompt like

“Generate 20 employee records with names, emails, job titles, and start dates after 2015.”

…and it will figures it out.

Behind the scenes, there’s a bit of AI involved — it reads your schema, parses your prompt, and comes up with data that fits both. The schema you defined is treated as the source of truth. So even if the AI gets creative, the result always gets checked, corrected, and cleaned up before it’s returned to you.

You end up with realistic data, shaped exactly how you wanted it, ready to copy, download, or feed directly into your app or tests.

If Something’s Off, It Fixes Just That

One of the most useful parts — and something that I honestly didn’t plan from the beginning — is how it handles mistakes. Sometimes, data doesn’t validate perfectly the first time. Maybe one field doesn’t match a regex. Maybe an array has too few items.

Instead of throwing everything out and trying again, MockingJar just regenerates the broken parts. It keeps what worked, replaces what didn’t. Like a quiet little assistant that says, “Hey, I’ve got this,” and moves on.

You don’t really notice it unless you’re paying attention — and that’s kind of the point.

Why It Feels Different

There are a lot of data generation tools out there. Some are great at generating fake names and emails. Some let you define schema in code. But they always felt disconnected to me — like I had to either do everything manually, or hand over control entirely.

MockingJar sits somewhere in the middle. You define the structure. You describe what you want. And it fills in the rest — realistically, reliably, and in a way that doesn’t fight you.

I didn’t build it to be clever. I just wanted to stop faking data by hand every time I started a new project.

Turns out, that was a pretty decent reason.

AI Didn’t Replace My Work as an Engineer — It Changed the Way I Think

I’ve seen a lot of conversations over the past few years about whether AI will replace software engineers.

And to be honest? Most of them miss the point.

AI isn’t replacing us.It’s reshaping how we work, what we focus on, and how we think about solving problems.

At least, that’s what it’s done for me.

In the past, writing software felt like a series of manual checkpoints. You’d plan a feature, build all the scaffolding, write boilerplate code, manually mock your data, wire up endpoints, and then finally, eventually, get to the “real” problem. It was a slow, linear climb.

Now? I skip half those steps without even realizing it.

The Shift From Manual to Mental

When AI tools became a real part of my workflow — autocomplete, code generation, chat-based debugging — something interesting happened. My job didn’t get easier, exactly. But it changed shape. I stopped spending energy on things I already knew how to do. Instead, I started thinking more like a problem designer than just a problem solver.

That’s a subtle but powerful shift.

I move faster now. I iterate more freely. I try ideas I would’ve skipped before because the setup would’ve taken too long. Prototyping became fun again — not because AI did it for me, but because I no longer had to sweat the small stuff to get moving.

AI Didn’t Take the Wheel — It Sat in the Passenger Seat

The more I’ve worked with AI, the more I’ve realized: it’s not here to take over. It doesn’t write perfect code. It doesn’t understand edge cases. It doesn't replace architecture or decision-making.

But what it does do — and this is huge — is amplify what I’m already good at.

It gives me momentum.It shortens the distance between idea and execution.It helps me think more clearly by letting me focus on structure, logic, and flow — not on syntax or boilerplate.

And because of that, I actually build more. I explore more. I solve better problems.

For example — a tool I built to help generate structured mock data from custom JSON schemas.

In the pre-AI era, I might have written the whole engine manually. It would’ve worked, but it would’ve been slow, rigid, and full of edge-case handling. Building a system that understands context, generates realistic sample data, and validates it against a schema would’ve been a month-long grind.

But with AI in the mix — not as the hero, but as a collaborator — I could do something better. I built the structure, the validation logic, the schema builder. Then I handed off the tedious part (inventing realistic, varied, sensible data) to the AI.

That’s the magic spot: I define the rules, and the AI plays within them.

It didn’t do the job for me.It let me do more of the job I actually care about.

The Way We Build Software Is Changing

What I’ve learned is this: AI hasn’t just changed the tools I use. It’s changed the questions I ask when I sit down to build something.

Instead of:

“How long will this take to implement?”

I now think:

“What’s the fastest way to prove if this works?”

Instead of spending time on setup, I jump straight into validation. I can test assumptions quickly. Mock APIs, fake data, generate ideas — and toss them just as fast if they don’t hold up.

This isn’t about replacing engineers.It’s about raising the floor, so we can focus on higher-level thinking. On design. On clarity. On impact.

Final Thoughts

I don’t see AI as a threat to engineering. I see it as a mirror. It shows us which parts of our work are mechanical, and which parts are irreplaceably human.

And if we use it well — as a partner, not a crutch — it makes us better.

Smarter. Faster. More creative.Not because it thinks for us, but because it frees us up to think better.

That’s the kind of progress I can get behind.