khalaf.ai

Everyday billions of critical actions—performed by surgeons, farmers, forklift drivers—fade away without leaving behind accessible, structured data. Meanwhile, software industries thrive because of their endless digital footprints.

Whatever data exists is already hoarded by the incumbents who built the machines. John Deere can figure out every seed planted; Intuitive Surgical knows every tremor of a scalpel. In a way, they're the only eyes in the room.

Software is no exception here; Proxycurl built a $10 million ARR business on scraped LinkedIn data until lawsuits forced their closure. Shaky foundations are turning into proprietary lock-ins.

Owning the data pipeline is more powerful than owning the best model. Once a vendor controls the raw footage, lock-in precedes intelligence and lock-in is permanent.

My Solution for Founders

You are not competing with the OEM.

Instead of challenging incumbents head-on, provide immediate autonomy benefits through retrofit hardware. I would pitch a simple proposition:

"Let us bolt this kit onto your fleet. You get instant autonomy features tomorrow; we both get more data."

Collaborating with nimble, intelligent teams is a powerful bet for institutions weighed down by bureaucracy and lack of intelligent talent.

Take Control of the Data Pipeline

Barrier-to-entry for hardware is at the lowest it's ever been. While you won't be building forklifts & assembly lines, you'll build add-on devices that capture even more data.

Productive value-adds can capture the same valuable data with a fraction of the overhead. Imagine a self-driving kit fitted onto a forklift that collects data on warehouses, performance, and use-cases.

Once the flywheel spins—data → fine-tuned models → better autonomy → more users → more data.

After over 2 years of AI development experimentation I've found my flow and transformed my role

I began like many others: testing local LLMs and cycling through the latest coding assistants. Nothing endured.

Early workflows were inefficient as they involved dragging files, copying outputs, pasting changes. MCP integrations promised structure but never worked.

The debate around coding with LLMs is polarized. Executives imagine full automation; skeptics dismiss the field outright. The truth is between these extremes.

For backend engineers like me, LLMs cut the friction of learning frameworks, trying multiple designs in parallel, and asking questions without hesitation.

The chat format quickly became a limitation. Tracking revisions and branches was impossible. Terminal-based tools like Claude Code helped, but remained costly and opaque.

Atlassian’s Rovo Agent changed that. With its beta release I could split sessions across repositories, generate prototypes, and review code properly inside VSCode.

I came up with a cool workflow:

Step 0: Figure out what you want to build

Can't help you with that one. Whatever it is, you should have a long brainstorming session where you write everything down before reviewing.

Step 1: Fight with the LM

Refine your brainstorm doc to get the gist of what you want then feed it into the LLM.

"Attached is the BRAINSTORM.md for Timeio, an automated timecard OCR processor. Go through the document and challenge decisions & assumptions made. Questions should be asked one by one and discussed at length before proceeding. Use the answers from the discussions to inform a new PRD in PRD.md."

The results are stunning. It's not just the magic of the PRD itself but the process by which you're actually digesting your own thoughts and second-guessing prior assumptions. By the end of the discussion (usually about an hour) the biggest transformation is in your own mental model of your now-refined plan.

Step 2: The Sprint Plan

We know what we're building now. Organize everything by generating a Sprint Plan. Atlassian's Rovo Agent has native Jira integration so I use that (free Claude credits under the hood).

Review the sprint plan once generated. Don't sweat the details much here because the PRD should cover the main requirements; this is for tackling tasks in an organized manner and making it easier for you to review the code piece-by-piece later.

Step 3: The Execution Sprint

Plan, vision, and sprint in hand. We're ready to go.

You've put in hours of work & now it's time to reap the rewards. The strong mental vision of the finished product, coupled with the documented detail will now come to fruition.

The sprint plan is now the central tracking mechanism for the coding agent(s).

Step 4: Back at The Wheel

Armed with all the context, you now review code. Yes you actually need to read it almost line-by-line and ask questions. I have a custom keybinding that drops a REVIEW: comment based on the filetype. After commenting my feedback there, I go back to Rovo and it addresses my concerns or challenges my thinking.

Closing out

• Mistakes I see: Treating LLMs as magic typewriters. Skipping design, planning, and documentation. Failing to integrate with task management or write tests. The real bottleneck is now system-level thinking, not typing speed.
• My role shifted upward. I spend my time on design, architecture, and database schemas.
• If AI coding feels shallow, start with planning. Write requirements by hand before using a model. Only then introduce an agent into the loop. Use tools that support review, write proper tests, and keep documentation alive. AI does not remove the work it just accelerates it.

teaching data structures & algos to hundreds of students made it clear what's missing

this writeup was inspired by my dear friend Khader - somebody who's always pushing me to grow

"it can't be me; it's the market"

I won't gaslight you. The job market for software professionals in the US is undeniably down, but it's not the market's job to fix your life.

live data, so maybe it'll be up by the time you see this?

Software "engineering" is far too broad a term. It includes everyone from embedded C driver wizards to a guy who built a website a year ago.

There is no degree, comittee, or professional exam to check if you know how software is built.

Enter: System Design

A core feature of software development is the architecting of software systems. Coding agents reduce the marginal cost of each LoC, making elegant architecture all the more important for capturing the benefits of AI.

I won't bore you. If you have no idea what system design is you should check out hellointerview.com. It's a great starting point for understanding what Redis vs Cassandra vs S3 vs . . . is all about.

System Design is best learned in production. My years working on AWS S3 definitely helped, but it's tough to land those opporutnities without understanding the basics.

At this stage focus on understanding, not completing. The goal of system design interviews is to break down the depth of your knowledge. We're looking for those who have the knowledge but can also use it creatively & come up with novel insights on the fly.

Data Structures & Algorithms

I've taught hundreds of students the gambit of data structures & algorithms.

The truth of this stage is, you need to do the reps.

The students I had that didn't excell were largely not putting in the work. Resources-wise, this is the most saturated space in all of software education content.

leetcode remains a gold standard for problem sets and new entrants have sprung up to deal with the understanding of DS&A. I hear neetcode.io is really good.

If you're in a hurry - go through the Blind75. It's meant to be as exhaustive as possible for the fewest questions required.

When I was practicing DS&A years ago, I dedicated my days just to problems. If you put in the work, you will develop a "second sense" for which solution is appropriate to the problems.

Don't focus on memorizing the problem, just focus on understanding why the optimal solution was optimal. If you do this reliably and with enough volume - you win.

Closing out

People lament software interviews for "not resembling the job". In reality, the 2 basic topics above are great for morphing your brain for the thinking required in backend systems development. System design in particular will make you a much more aware developer. I would consider it the closest thing we have to actual "engineering".

Before you start, put together a strict calendar and treat System Design like a college course - learning and evaluating constantly. DS&A is a craft - set aside lots of training windows and you'll fly through problems before you know it. Focus a week on DS&A literature at most before diving head first into problems. Don't overthink that part.