Software Engineer (AI-Forward)

ABOUT US

Tight Line is a small software consultancy. Our engineers work on client teams at companies like Internet Brands/WebMD, and on our own research and open-source work.

ROLE SUMMARY

We want an engineer with good taste who does nearly all of their work with an AI in the loop, and who never mistakes the AI's output for their own judgment.

We don't care much which language you write. You should have shipped real work in at least two major languages (some mix of Python, Go, TypeScript, PHP, Java, Ruby, C#, etc.) and in at least two frameworks that look nothing alike (Laravel and React, say, or Spring and Next.js). That's for perspective. If you've only seen one way of doing things, it's hard to tell which parts matter and which are just habits.

WHAT YOU NEED TO UNDERSTAND

1. How systems fit together
   By "system" we mean some collection of software connected to the Internet: DNS, TLS, load balancers, queues, databases, caches, auth, the deploy pipeline, and the logs you'll be reading when it breaks. You don't need to be an expert in all of it. You do need to be able to sketch it, explain it, and understand how the pieces work together.

2. What good and bad design look like
   You know what a normalized schema looks like and when to denormalize anyway. You can tell a clean API from one that's going to cause trouble, and you can say why. Modularity, testing, CI/CD, config and observability are all things you have opinions about, because you learned the hard way. You can tell when a project is mis-designed and when it's over-engineered, and you know those are different problems with different fixes.

   This should be in your bones. A design where the filesystem doubles as the authoritative database should bother you. So should a proxy that adds a hop and a bottleneck and nothing else.

3. How to work in existing code
   Most of this job is changing code someone else wrote. You read it before you change it, and you figure out why it's shaped the way it is (sometimes there's a good reason). Then you make the change the problem calls for and no bigger. A one-line fix ships as a one-line fix with a test. A refactor gets its own PR.

4. How to build something new without overbuilding it
   When you do start from scratch, you build the simplest thing that will hold up once real users touch it. You don't build a plugin architecture for a tool with one plugin, or microservices for a team of three. You leave room to grow, but you don't build the growth ahead of time.

5. When to buy (or download) instead of build
   The best code is code you didn't have to write. Before you build, you check whether a maintained library, open-source project or SaaS product already does the job. You can also tell when bending the off-the-shelf thing will cost more than writing it. "Does the existing software already support LDAP?" is a question you ask before you write an LDAP integration.

6. How to communicate
   Most of our work is async and across a lot of time zones, so clear written English is a must. Your PR descriptions say what changed and why. You flag uncertainty instead of hiding it. You disagree out loud, and you give your reasoning as clearly as possible. You can explain a tradeoff to a client stakeholder without hand-waving or talking down to them.

AI-FORWARD, IN PRACTICE

This part really matters to us. AI is your default tool for nearly everything, and you own the result. Some examples:

• An annoying, repetitive task? The AI writes the script, or just does the task, and you check the output.

• A new codebase? Before you touch anything, you question the AI about it: where auth happens, why a table is shaped that way, what calls a given function, what breaks if you change it. You check the answers that matter against the code.

• Scaffolding a new app, service or CLI? Hand the shell to the AI. Spend your own attention on the data model, the interfaces and the failure modes.

• Tests? The AI writes most of them. You read them, and you notice when a test asserts nothing, mocks out the thing it claims to test, or only covers the happy path. "How are you testing this, and how did you miss that?" is something you say to the AI regularly.

• Code review? AI review is your first pass and your second opinion. You still do the review that counts.

• Docs, runbooks, migration plans and incident write-ups? The AI drafts them. You edit until they sound like a person wrote them.

• Your tooling? You improve it as you go: project instructions (CLAUDE.md / AGENTS.md), reusable skills and prompts, MCP servers, small automations. When the AI makes the same mistake twice, you fix its instructions so there isn't a third time.

You also know when to rein it in. "Step back and simplify this." "Why do you need that?" "Don't go overboard on the comments." When the model proposes three new abstractions to fix one bug, you're the one who says no.

We use Claude Code heavily. You should have real experience with Claude Code, Cursor, Codex or a similar agentic tool. Which one matters much less than how you use it.

WHAT WE'RE NOT LOOKING FOR

Vibe coders. If your workflow is to prompt until it compiles, keep pasting until the tests go green, and ship code you couldn't defend in a review, this isn't the job.

We're also not a fit for people who distrust AI on principle and only use it for autocomplete. Both miss the point in the same way. This job only works when your judgment and the tool work together.

QUALIFICATIONS YOU MUST HAVE

• 5+ years building and running production software

• Shipped work in at least two major languages and two very different frameworks

• A good working knowledge of Linux, git, containers, and at least one major cloud

• Solid relational database skills, including writing your own SQL when it matters

• AI-forward work you can actually show us

Nice to have: Kubernetes, OpenTelemetry or other observability work, open-source contributions, consulting or client-facing experience.

HOW TO APPLY

Send your CV and a short note, written by you, about a recent piece of work you did with an AI agent. Tell us what you handed off, what you checked, and at least one place where the AI was wrong and you caught it. If you can share a PR or session transcript, even better.

Our interviews include a working session in an unfamiliar codebase, using whichever AI tool you prefer. We pay more attention to the questions you ask it than to the code it writes.