Thinking Like a Developer

AI coding tools are teaching non-developers something unexpected: how to think like engineers. Not the programming part. The part about structuring information, managing context, and organizing work so the next step can actually use what you've created.

Thinking Like a Developer

Something happens when you start using coding tools

You don't set out to learn version control. You set out to automate a report, or build a small tool, or just see what Claude Code can do. Then you hit a problem. You need the AI to understand your project. It needs context. And suddenly you're thinking about how your files are organized, what format your data is in, and whether the tool can actually access what it needs.

You're not coding. But you're thinking like someone who codes.

The convergence nobody expected

There's a quiet shift happening. The tools developers use to write software (Git, the terminal, Markdown, structured data) are becoming the tools everyone uses to work with AI.

Not because anyone decided this should happen. But because AI coding tools are the most capable AI tools we have right now, and they work best with the same patterns developers have used for decades.

Think about what a developer does all day. Organize information so other systems can process it. Track changes. Write things down in formats that tools can read. Break big problems into smaller pieces. Build workflows where each step feeds into the next.

That's increasingly what working with AI looks like, regardless of your job title.

The "you don't need to know this" trap

New tools keep promising you don't need to be technical. Upload your files, ask questions, let the AI figure it out. And for simple things, that works.

But spend a week with these tools and you notice the gap. Someone who understands how context works, how data needs to be structured, what the tool can actually see and what it can't. They get dramatically different results. Not because they're smarter. Because they understand the system they're working with.

It's the difference between someone who uses Excel to make tables and someone who understands data types and formulas. Same tool. Different universe of what's possible.

The practices that matter (and why developers put up with them)

Git is a good example. It tracks every change to every file, lets you undo anything, shows you exactly what changed and when. Developers have used it for 20 years. It's also genuinely confusing to learn. The commands make no intuitive sense. The mental model takes time to build.

So why do developers tolerate it? Because once you have version control, you can't go back. Every edit is tracked. Every version saved. You can go back to last Tuesday's version because the client changed their mind again. Multiple people work on the same files without destroying each other's progress.

Now think about how most teams manage their project files. Shared drives with "strategy_doc_v3_FINAL_actually_final.docx." No history. No way to see what changed between versions. No way to undo last week's edits without manually comparing documents.

Developers solved this problem decades ago. The solution is just now becoming relevant to everyone else.

Context is the real skill

Here's what becomes clear after a few weeks with AI coding tools: the quality of your output depends almost entirely on the quality of your context.

Context means: what does the AI know about your project? What files can it see? What are the rules and constraints? What happened before this conversation?

Developers manage context constantly. They write README files. They maintain project documentation in the repository. They keep configuration explicit and version-controlled. None of this is coding. All of it is essential to making the tools work.

When you start applying the same thinking to any knowledge work, things change. Instead of a strategy living in someone's head (or buried in a slide deck from three months ago), it's a document the AI can reference. Instead of scattered notes across five apps, there's a structured place where context accumulates.

Where this goes

Right now, most people save information for other people to read. Formatted documents, presentations, spreadsheets with merged cells. It looks good. It presents well.

But increasingly, the next thing reading your work won't be a person. It'll be an AI that needs to extract, transform, or build on what you've written. And that tool doesn't care about formatting. It cares about structure.

We're moving toward a pattern where you organize information for the process that comes after you. You write a project brief not just for colleagues to read, but for an AI to act on. You structure data not just for a meeting, but for the next automated step that you design and oversee but don't do yourself.

Developers have always worked this way. They write code for machines to execute, not for humans to admire. The rest of knowledge work is starting to follow the same logic.

You don't need a CS degree

None of this requires programming ability. It requires a way of thinking. What format is this data in? Can my tools actually read it? How do I organize this so the next step (human or AI) can work with it efficiently? What context does this process need?

These are the questions developers ask automatically. AI tools are now creating the same need for everyone who works at a computer.

The people pulling ahead right now aren't necessarily the most technical. They're the ones who noticed that their tools have opinions about how information should be structured, and decided to listen.